I wrote:
> justin.vanwinkle@gmail.com writes:
>> select '{"a": {"b":{"c": "foo"}}}'::jsonb #> '{}';
>> [ dumps core ]
> Hm. It's not immediately obvious to me what this should be defined to do;
> should it throw an error, or return the complete LHS object, or perhaps
> return a NULL? But the author of get_jsonb_path_all() evidently didn't
> consider the case.
It occurred to me to check what the pre-existing JSON-type code does with
this case, and I find it returns NULL. So there's certainly an argument
to be made for following that precedent and calling it a day. However,
on reflection it seems to me that this behavior is entirely nonsensical,
and the sane thing to do is to return the given json or jsonb input.
Surely #> with a K-element path ought to act the same as K invocations
of the -> operator ... and zero invocations would result in just having
the original input object, no?
So I propose that we fix both operators to return the input object in this
case, and release-note the change in behavior from 9.3.
BTW, the same argument would suggest that if the array contains null
elements, the right thing to do is return NULL, not throw an error
as the current code does. You would get a NULL if you passed a NULL
RHS to ->, because it's strict.
regards, tom lane