Re: [HACKERS] json/jsonb/hstore operator precedence
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... -- 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
Re: [HACKERS] json/jsonb/hstore operator precedence
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] json/jsonb/hstore operator precedence
On 04/01/2014 01:07 PM, Andrew Dunstan wrote: 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. ... and it would probably break umpty-zillion existing apps if we changed precedence. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] json/jsonb/hstore operator precedence
On 4/1/14, 3:07 PM, Andrew Dunstan wrote: 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. I'm confused... first you say there's no precedence and then you're saying that there is? Which is it? ISTM that most languages set the priority of de-referencing operators to be quite high, so I don't see how that would be a disaster? Of course, changing the precedence of = and certainly would be a disaster; I'm not suggesting that. -- 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
Re: [HACKERS] json/jsonb/hstore operator precedence
On 04/01/2014 05:42 PM, Jim Nasby wrote: On 4/1/14, 3:07 PM, Andrew Dunstan wrote: 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. I'm confused... first you say there's no precedence and then you're saying that there is? Which is it? No I didn't say there was no precedence. Please reread what I said. I said there was no provision for setting the precedence. There is precedence of course, but it's hardcoded. ISTM that most languages set the priority of de-referencing operators to be quite high, so I don't see how that would be a disaster? The way the grammar works ALL the composite operators have the same precedence. It has no notion that - is a dereference operator. You're suggesting something without actually looking at the code. Look at gram.y and scan.l and you might understand. Of course, changing the precedence of = and certainly would be a disaster; I'm not suggesting that. There is arguably nothing wrong with the precedence of - and -. The reason for the problem Greg reported is that probably has its precedence set too low. And no, we can't change it. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] json/jsonb/hstore operator precedence
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
