> 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).