Re: Document NULL

On Thu, Nov 21, 2024 at 6:50 AM Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:

> About JSONB_PATH, you said that "JSON null value is considered equal to
> other JSON null values", but didn't say anything about IS DISTINCT FROM
> at jsonb_path level. Wouldn't be good to mention something about it ?
>
> select '{1,2}'::integer[] is distinct from null::integer[]
> select jsonb_path_exists('[null]', '$[*] ? (@ == null)')
>
>
I'm not following your train of thought here. Since null == null in
json-land there isn't a need for or concept of "is distinct from". We tend
to not expend space on pointing out things that don't exist, and while I'm
actually one to want to violate that principle more often than not this
doesn't seem like a place for an exception. Especially without being
motivated by end-user questions.

I'm glad they did it for semantics but the need for the path operator "@ is
unknown" is redundant with just saying (@ == null). Pointing that out
seems a bit superfluous though. The nulls equals each other is the key
point to remember and then everything else works just as one would expect
under that condition.

I may end up calling out this dynamic though (not related to json_path
though possibly has an equivalent there, will need to look or be pointed to
the relevant section).

UPDATE statements may use subscripting in the SET clause to modify jsonb
values. Subscript paths must be traversable for all affected values insofar
as they exist. For instance, the path val['a']['b']['c'] can be traversed
all the way to c if every val, val['a'], and val['a']['b'] is an object. If
any val['a'] or val['a']['b'] is not defined, it will be created as an
empty object and filled as necessary. However, if any val itself or one of
the intermediary values is defined as a non-object such as a string,
number, or jsonb null, traversal cannot proceed so an error is raised and
the transaction aborted.

David J.