json/jsonb/hstore operator precedence

From: Greg Stark <stark(at)mit(dot)edu>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: json/jsonb/hstore operator precedence
Date: 2014-03-18 17:13:52
Message-ID: CAM-w4HO6u+8Tyn=6CYbOAa67DBmq1WjAgc67_d92tyz+sx_gpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-03-18 17:16:27 Re: GSoC proposal. Index-only scans for GIST
Previous Message Sandro Santilli 2014-03-18 17:04:01 Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)