Re: [HACKERS] Odd/undocumented precedence of concatenation operator

[Shay Rojansky]

>
> It is expected, and documented.  (It's also different in 9.5, see
>
> http://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=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.

Re: [HACKERS] Odd/undocumented precedence of concatenation operator

[Tom Lane]

Shay Rojansky  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=commitdiff=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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers