On 03/31/2016 09:00 AM, Dmitry Dolgov wrote:
> On 31 March 2016 at 17:31, Vitaly Burovoy <vitaly.burovoy@gmail.com
> <mailto:vitaly.burovoy@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.
cheers
andrew
