Bryn Llewellyn <bryn@yugabyte.com> writes:
> I'm going to try to think like this:
> The number of possible spellings of the names of keys in a JSON object is some flavor of infinite. So including this
inan object:
> "k": null
> really is saying something. It says that I do know about "k" and that yet I have simply no information available
aboutits value.
I'd read it as asserting that key "k" is meaningful for this object,
but the correct value for that key is not known.
I have a hard time with your assertion that {"x": 42, "y": null}
should be considered equivalent to {"x": 42}, because it would
render key-exists predicates useless. Either you have to say that
key "y" is claimed to exist in both of these objects and indeed every
object, or you have to make it fail if the key's value is null (so that
it'd say "false" in both of these cases). Either of those options
seems both weird and useless.
> The quirkiness that my first example showed can be seen differently from how I saw it first. When I now consider this
expression:
> ('{"x": 42}'::jsonb)->>'y'
> it seems that its evaluation should simply raise an exception. But you said:
>> This produces "key y not present in JSON" but someone decided that was too unfriendly and so we instead produce SQL
NULL.
Right. This is hard to justify from a purist semantic point of view,
but having the operator throw an error in such cases would make it
close to unusable on not-uniformly-structured data. And really the
point of using JSON inside a SQL database is to cope with irregularly-
structured data, so fuzziness seems like what we want.
regards, tom lane