Andrew Dunstan <andrew@dunslane.net> writes:
> On 08/20/2014 03:06 PM, Tom Lane wrote:
>> Peter Geoghegan <pg@heroku.com> writes:
>>> Andrew argued it was
>>> preferable to stick to the historic behavior of json operators. IMV,
>>> we should have both operators return NULL. They should be consistent,
>>> which implies changing the behavior of the existing json variants too,
>>> but I don't think that's a big problem.
>> None of these operators existed before 9.3, so I don't put a lot of stock
>> in the idea that their corner-case behaviors should be considered
>> sacrosanct already. But that will become the case pretty soon; if we
>> don't get it right in 9.4 it will arguably be too late.
> I'm not terribly dogmatic about it. If the consensus is to change it
> then let's do it.
Well, if the preference is to make jsonb conform to the historical
behavior of json, we have work to do anyway. I noted this inconsistency
while drawing up some test cases:
regression=# SELECT '42'::json #> array['f2'];
?column?
----------
(1 row)
regression=# SELECT '42'::jsonb #> array['f2'];
ERROR: cannot extract path from a scalar
In this particular case the json code is self-inconsistent, since ->
throws an error:
regression=# SELECT '42'::json -> 'f2';
ERROR: cannot extract element from a scalar
regression=# SELECT '42'::jsonb -> 'f2';
ERROR: cannot call jsonb_object_field (jsonb -> text) on a scalar
I think returning NULL is the right thing here, really. Aside from being
arguably more convenient for indexing, we will get less push-back if we
make some operators go from throwing errors to returning null than if
we make some other operators go the other way.
regards, tom lane