On Thu, Nov 21, 2024 at 6:50 AM Marcos Pegoraro <marcos@f10.com.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[]
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.
