Re: jsonb_set() strictness considered harmful to data

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Mark Felder <feld(at)freebsd(dot)org>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: jsonb_set() strictness considered harmful to data
Date: 2019-10-19 16:32:54
Message-ID: CAKFQuwa0epfqMsJ=yz8t+ASmdf5PoFXhXj=9DBpoHa2i_67nJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Sat, Oct 19, 2019 at 9:19 AM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

> >
> >We invented jsonb_set() (credit to Dmitry Dolgov). And we've had it
> >since 9.5. That's five releases ago. So it's a bit late to be coming to
> >us telling us it's not safe (according to your preconceptions of what it
> >should be doing).
> >
>

There have been numerous complaints and questions about this behavior in
those five years; and none of the responses to those defenses has actually
made the current behavior sound beneficial but rather have simply said
"this is how it works, deal with it".

>
> >We could change it prospectively (i.e. from release 13 on) if we choose.
> >But absent an actual bug (i.e. acting contrary to documented behaviour)
> >we do not normally backpatch such changes, especially when there is a
> >simple workaround for the perceived problem. And it's that policy that
> >is in large measure responsible for Postgres' deserved reputation for
> >stability.
> >
>
> Yeah.
>
>
Agreed, this is v13 material if enough people come on board to support
making a change.

>
> >And if we were to change it I'm not at all sure that we should do it the
> >way that's suggested here, which strikes me as no more intuitive than
> >the current behaviour. Rather I think we should possibly fill in a json
> >null in the indicated place.
> >
>
> Not sure, but that seems rather confusing to me, because it's mixing SQL
> NULL and JSON null, i.e. it's not clear to me why
>
[...]

> But I admit it's quite subjective.
>

Providing SQL NULL to this function and asking it to do something with that
is indeed subjective - with no obvious reasonable default, and I agree that
"return a NULL" while possible consistent is probably the least useful
behavior that could have been chosen. We should never have allowed an SQL
NULL to be an acceptable argument in the first place, and can reasonably
safely and effectively prevent it going forward. Then people will have to
explicitly code what they want to do if their data and queries present this
invalid unknown data to the function.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Dunstan 2019-10-19 16:47:39 Re: jsonb_set() strictness considered harmful to data
Previous Message Andrew Dunstan 2019-10-19 16:32:10 Re: jsonb_set() strictness considered harmful to data

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-10-19 16:44:49 Re: pgsql: Implement jsonpath .datetime() method
Previous Message Andrew Dunstan 2019-10-19 16:32:10 Re: jsonb_set() strictness considered harmful to data