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
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 ?) |