From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: SQL-spec incompatibilities in similar_escape() and related stuff
In-reply-to: <87k1eufem8.fsf@news-spur.riddles.org.uk>
References: <14047.1557708214@sss.pgh.pa.us>
 <8736lihni6.fsf@news-spur.riddles.org.uk>
 <87v9yeg69c.fsf@news-spur.riddles.org.uk>
 <87k1eufem8.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Mon, 13 May 2019 18:43:08 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4485.1557769997.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 May 2019 13:53:17 -0400
Message-ID: <4486.1557769997@sss.pgh.pa.us>
Precedence: bulk

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Andrew" =3D=3D Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>  Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
>  Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
>  Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
>  Andrew> as part of the function syntax. But I think this is probably a
>  Andrew> non-issue. More significant is that ... COLNAME ! ESCAPE ...
>  Andrew> again has postfix- vs. infix-operator ambiguities.

> And this ambiguity shows up already in other contexts:

> select 'foo' similar to 'f' || escape escape escape from (values ('oo'))=
 v(escape);
> psql: ERROR:  syntax error at or near "escape"
> LINE 1: select 'foo' similar to 'f' || escape escape escape from (va...


Hmm.  Oddly, you can't fix it by adding parens:

regression=3D# select 'foo' similar to ('f' || escape) escape escape from =
(values ('oo')) v(escape);
psql: ERROR:  syntax error at or near "escape"
LINE 1: select 'foo' similar to ('f' || escape) escape escape from (...
                                        ^

Since "escape" is an unreserved word, I'd have expected that to work.
Odd.

The big picture here is that fixing grammar ambiguities by adding
precedence is a dangerous business :-(

			regards, tom lane