Fwiw I'm finding myself repeatedly caught up by the operator
precedence rules when experimenting with jsonb:
stark=***# select segment->'id' as id from flight_segments where
segment->>'marketing_airline_code' <>
segment->>'operating_airline_code' ;
ERROR: 42883: operator does not exist: text <> jsonb
LINE 2: ...segments where segment->>'marketing_airline_code' <> segment...
^
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.
LOCATION: op_error, parse_oper.c:722
Time: 0.407 ms
stark=***# select segment->'id' as id from flight_segments where
(segment->>'marketing_airline_code') <>
(segment->>'operating_airline_code') ;
id
-------------
"45866185"
"95575359"
....
I don't think this is related to the jsonb patch -- json and hstore
have the same behaviour so jsonb is obviously going to follow suit.
The only option right now would be to use a higher precedence operator
like % or ^ for all of these data types which I'm not for. I suspect
it's a pipe dream to think we might be able to override the '.' and
changing the precedence of -> and ->> would be fraught...
I think the best we can do is to highlight it in the docs.
Incidentally it's a good thing there wasn't an implicit cast
text->jsonb. In this case it would have resulted in just a confusing
error of jsonb->>boolean not existing.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
