Re: json/jsonb/hstore operator precedence

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: json/jsonb/hstore operator precedence
Дата
Msg-id 533B1C83.105@dunslane.net
обсуждение исходный текст
Ответ на Re: json/jsonb/hstore operator precedence  (Jim Nasby <jim@nasby.net>)
Ответы Re: json/jsonb/hstore operator precedence  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On 04/01/2014 03:40 PM, Jim Nasby wrote:
> 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 do if there's some 
> way to manage the backwards compatibility...


There is no provision for setting the precedence of any operators. The 
precedence is set in the grammar, and these all have the same 
precedence. What you're suggesting would a cure far worse than the 
disease, I strongly suspect. You just need to learn to live with this.

What really bugs me about the example is that <> has a different 
precedence from =, which seems more than odd. The example works just 
fine if you use = instead of <>. But I guess it's been that way for a 
very long time and there's not much to be done about it.

cheers

andrew




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Следующее
От: Jerry Sievers
Дата:
Сообщение: Ok to flip pg_constraint.condeferrable on 9.1?