Re: json/jsonb/hstore operator precedence
От | Jim Nasby |
---|---|
Тема | Re: json/jsonb/hstore operator precedence |
Дата | |
Msg-id | 533B162D.2020704@nasby.net обсуждение исходный текст |
Ответ на | json/jsonb/hstore operator precedence (Greg Stark <stark@mit.edu>) |
Ответы |
Re: json/jsonb/hstore operator precedence
|
Список | pgsql-hackers |
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: > > 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 doif there's some way to manage the backwards compatibility... -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: