On 3/18/14, 12:13 PM, Greg Stark wrote:
Fwiw I'm finding myself repeatedly caught up by the operator precedence rules when experimenting with jsonb:Advertising
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.
Wow, that really sucks. :( What are cases where things would break if we changed the precedence of -> and ->>? ISTM that's what we really should do if there's some way to manage the backwards compatibility... -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
