From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: SQL-spec incompatibilities in similar_escape() and related stuff |
Date: | 2019-05-13 17:53:17 |
Message-ID: | 4486.1557769997@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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=# 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-05-13 18:05:59 | Re: POC: Cleaning up orphaned files using undo logs |
Previous Message | Andres Freund | 2019-05-13 17:52:21 | Re: [HACKERS] Unlogged tables cleanup |