I sometimes do this in plugins, where the queries are under control. But for the core usage the regex pattern looks a bit fragile:

safe_upsert(
    'txp_lang', 
    'data = "My data", event = "public"',
    'data = "TWIST AND SHOUT"'
)

If you find a more robust pattern, I'll be all for it.

How about that?

That's better, but still will not work with a=1 AND b=2. And if we add \d (digital) to ('|") collection as before AND delimiter, c="1 AND 1" will break it. Tough case...

An easier way would be to pass an array of clauses as $where argument. But I don't know if it helps in your use case.

Yes, why not; otherwise \d seems to work.

Edit: better here.

…but $where as an array would be probably cleaner.

Still broken for a='1 AND one'. There are also a=NOW() AND b=1 and the likes to treat.

This is funny to do but I'm not sure if it makes sense to continue…
Any idea how it could work with an array?
Anyway, I can customize safe_upsert() in my plugin on my side.

You'd call it like this:

safe_upsert(
    'txp_lang', 
    'data = "My data", event = "public"',
    array('name = "my_data"', 'lang = "en-gb"')
)

If this is ok, I can submit a (backwards compatible) patch.

Perhaps even this, so it's not even possible to use any operator other than '=' in the where part:

safe_upsert(
    'txp_lang', 
    'data = "My data", event = "public"',
    array('name' => 'my_data', 'lang' => 'en-gb')
)

Perhaps, but since we need to insure the bwc, it would be inconsistent with former name = "my_data" clauses.

How about the operator? It would always be AND?

Only AND, I guess, unless we agree on some natural logic to assign values when a=1 OR b=2 is not found.

For me, this kind of thing (customized for clarity):

safe_upsert(
    'txp_lang', 
    'data = "My data", event = "public"',
    'name = "my_data" OR lang = "en-gb"'
)

would assign my_data to the column name and en-gb to lang.
However this could be a problem:

safe_upsert(
    'txp_lang', 
    'data = "My data", event = "public"',
    'name = "my_data" OR name = "your_data"'
)

…?

Bump? Is this targeted for 4.6?

Is this targeted for 4.6?

Not really, I think. It would make plugins authors life a little more convenient, but we (well, I) don't see a natural way to satisfy all the requirement. The best I can do now is follow Ruud's proposal and treat only AND operator, if nobody finds a better idea.

I agree, let see if we can find something better for 4.7, pending that plugin authors can build a custom function. I can close this pull request and open an issue…?

To be continued…

I just tripped over this one too (also in combination with setting the language). Has there been a solution to this, or does one have to do this in two stages:

• check if it exists:
  • if yes, do safe_update with where A AND B,
  • if no, safe_insert with all the columns.

It should work with AND arrays as suggested by Ruud.

Thanks Oleg. That did it!