From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: SQL-spec incompatibilities in similar_escape() and related stuff |
Date: | 2019-05-13 07:42:56 |
Message-ID: | 87v9yeg69c.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
Tom> SIMILAR and ESCAPE as keywords already, but they're
Tom> type_func_name_keyword and unreserved_keyword respectively. To
Tom> support this syntax, I'm pretty sure we'd have to make them both
Tom> fully reserved.
Andrew> I only did a quick trial but it doesn't seem to require
Andrew> reserving them more strictly - just adding the obvious
Andrew> productions to the grammar doesn't introduce any conflicts.
Digging deeper, that's because both SIMILAR and ESCAPE have been
assigned precedence. Ambiguities that exist include:
... COLNAME ! SIMILAR ( ...
which could be COLNAME postfix-op SIMILAR a_expr, or COLNAME infix-op
function-call. Postfix operators strike again... we really should kill
those off.
The ESCAPE part could in theory be ambiguous if the SIMILAR expression
ends in a ... SIMILAR TO xxx operator, since then we wouldn't know
whether to attach the ESCAPE to that or keep it as part of the function
syntax. But I think this is probably a non-issue. More significant is
that ... COLNAME ! ESCAPE ... again has postfix- vs. infix-operator
ambiguities.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2019-05-13 07:55:19 | Re: PANIC :Call AbortTransaction when transaction id is no normal |
Previous Message | 张连壮 | 2019-05-13 07:30:54 | pg_stat_database update stats_reset only by pg_stat_reset |