Thread: Odd/undocumented precedence of concatenation operator
Hi hackers.
Trying to execute the following query on PostgreSQL 9.4.4:
select 'a' >= 'b' || 'c';
Gives the result "falsec", implying that the precedence of the string concatenation operator is lower than the comparison operator. Changing the >= into = provides the result false, which is less surprising.
Is this the expected behavior, considering that >= and = behave differently and that + ranks much higher?
If nothing else, it seems that the concatenation operator should be listed on the operator precedence table at http://www.postgresql.org/docs/9.4/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE?
Thanks!
Shay
Shay Rojansky <roji@roji.org> writes: > Trying to execute the following query on PostgreSQL 9.4.4: > select 'a' >= 'b' || 'c'; > Gives the result "falsec", implying that the precedence of the string > concatenation operator is lower than the comparison operator. Changing the > >= into = provides the result false, which is less surprising. > Is this the expected behavior, considering that >= and = behave differently > and that + ranks much higher? It is expected, and documented. (It's also different in 9.5, see http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c6b3c939b7e0f1d35f4ed4996e71420a993810d2) > If nothing else, it seems that the concatenation operator should be listed > on the operator precedence table at > http://www.postgresql.org/docs/9.4/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE Both >= and || fall into the "any other operator" case, no? regards, tom lane
It is expected, and documented. (It's also different in 9.5, see
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=c6b3c939b7e0f1d35f4ed4996e71420a993810d2)
Ah, thanks!
> If nothing else, it seems that the concatenation operator should be listed
> on the operator precedence table at
> http://www.postgresql.org/docs/9.4/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE
Both >= and || fall into the "any other operator" case, no?
I somehow missed that in the table, assuming that >= would be somewhere with > and =. Thanks again.