Re: Odd/undocumented precedence of concatenation operator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shay Rojansky <roji(at)roji(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd/undocumented precedence of concatenation operator
Date: 2015-09-08 18:20:31
Message-ID: 24772.1441736431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Shay Rojansky <roji(at)roji(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2015-09-08 18:22:08 Re: Autonomous Transaction is back
Previous Message Andres Freund 2015-09-08 18:19:08 Re: Separating Buffer LWlocks