On 03/31/2016 09:00 AM, Dmitry Dolgov wrote:
On 31 March 2016 at 17:31, Vitaly Burovoy <vitaly.buro...@gmail.com <mailto:vitaly.buro...@gmail.com>> wrote:

    it is logical to insert new value if "before", then current value,
    then new
    value if "after".

Oh, I see now. There is a slightly different logic: `v` is a current value and `newval` is a new value. So basically we insert a current item in case of "after", then a new value (if it's not a delete operation), then a current item in case of "before". But I agree, this code can be more straightforward. I've attached a new version, pls take a look (it contains the same logic that you've mentioned).

I haven't been following this thread due to pressure of time, so my apologies in advance if these comments have already been covered.

I've been asked to look at and comment on the SQL API of the feature. I think it's basically sound, although there is one thing that's not clear from the regression tests: what happens if we're inserting into an object and the key already exists? e.g.:

select jsonb_insert('{"a": {"b": "value"}}', '{a, b}', '"new_value"');

I think this should be forbidden, i.e. the function shouldn't ever overwrite an existing value. If that's not handled it should be, and either way there should be a regression test for it.



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to