On Wed, 2019-10-23 at 13:00 -0600, Stuart McGraw wrote:
> > You can only say that if you don't understand NULL (you wouldn't be alone).
> > If I modify a JSON with an unknown value, the result is unknown.
> > This seems very intuitive to me.
>
> Would you expect modifying an array value with an unknown would result
> in the entire array being unknown?
Hm, yes, that is less intuitive.
I was viewing a JSON as an atomic value above.
> > One could argue that whoever uses SQL should understand SQL.
> >
> > But I believe that it is reasonable to suppose that many people who
> > use JSON in the database are more savvy with JSON than with SQL
> > (they might not have chosen JSON otherwise), so I agree that it makes
> > sense to change this particular behavior.
>
> That (generally) SQL NULL results in NULL for any operation has been
> brought up multiple times in this thread, including above, as a rationale
> for the current jsonb behavior. I don't think it is a valid argument.
>
> When examples are given, they typically are with scalar values where
> such behavior makes sense: the resulting scalar value has to be NULL
> or non-NULL, it can't be both.
>
> It is less sensible with compound values where the rule can apply to
> individual scalar components. And indeed that is what Postgresql does
> for another compound type:
>
> # select array_replace(array[1,2,3],2,NULL);
> array_replace
> ---------------
> {1,NULL,3}
>
> The returned value is not NULL. Why the inconsistency between the array
> type and json type? Are there any cases other than json where the entire
> compound value is set to NULL as a result of one of its components being
> NULL?
That is a good point.
I agree that the behavior should be changed.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com