> On Thu, 8 Nov 2018 at 16:19, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > On Thu, 8 Nov 2018 at 06:14, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> >> Now it's my turn to disagree. As an argument I have this thread [1], where
> >> similar discussion happened about flexibility of jsonb and throwing an errors
> >> (in this particular case whether or not to throw an error when a non existing
> >> path was given to jsonb_set).
> >
> > It doesn't mean so it is designed well.
> >>
> >> I can imagine significant number of use cases when adding a value to jsonb like
> >> that is desirable outcome, and I'm not sure if I can come up with an example
> >> when strictness is the best result. Maybe if you have something in mind, you
> >> can describe what would be the case for that? Also as I've mentioned before,
> >> consistency between jsonb_set and jsonb subscripting operator will help us to
> >> avoid tons of question about why I can do this and this using one option, but
> >> not another.
> >
> > I have only one argument - with this behave nobody knows if value was appended or updated.
>
> Well, maybe you're right, and I would love to discuss our approach to modify
> jsonb values, but the point is that the purpose of this patch is to
> provide a new
> "friendly" syntax to do so, not to change how it works or provide an
> alternative version of update functionality.
>
> Even if you'll convince me that subscripting for jsonb now should behave
> differently from jsonb_set, I would suggest to do this within a separate patch
> set, since the current one is already too big (probably that's why the review
> process is so slow).
I've noticed, that patch has some conflicts, so here is the rebased version.
Also, since people are concern about performance impact for arrays, I've done
some tests similar to [1], but agains the current master - results are similar
so far, I've got quite insignificant difference between the master and the
patched version.
[1]: https://www.postgresql.org/message-id/CA%2Bq6zcV8YCKcMHkUKiiUM3eOsq-ubb%3DT1D%2Bki4YbE%3DBYbt1PxQ%40mail.gmail.com
