Re: [HACKERS] Add hint for function named "is" - Mailing list pgsql-hackers

On Fri, Aug 12, 2016 at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's likely that by rejiggering the precedence of productions, we could
> resolve these ambiguities in favor of "it's not a ColLabel if it appears
> in a context like this".  And probably that wouldn't be too surprising
> most of the time.  But depending on precedence to resolve fundamentally
> ambiguous grammar is always gonna bite you sometimes.  People understand
> it (... usually ...) in the context of parsing multi-operator expressions,
> but for other things it's not a great tool.

I poked at this a little more today.  It might be a little easier to
shoot for changing "a_expr IDENT" to "a_expr ColId" than to shoot for
allowing "a_expr ColLabel", or even just allowing both "a_expr IDENT"
and "a_expr unreserved_keyword".  With the rule for postfix operators
is removed, following unreserved keywords are problematic: DAY FILTER
HOUR MINUTE MONTH OVER SECOND VARYING WITHIN WITHOUT YEAR.  I think
allowing ColId would create further problems with PRECISION, CHAR, and
CHARACTER as well.  But they are all shift/reduce conflicts, which
somehow scare me quite a bit less than the reduce/reduce conflicts one
gets when trying to allow ColLabel.

I think there would be a lot of value in coming up with some kind of
incremental improvement here; this is a common annoyance for users
migrating from other database systems (and one in particular).  We
currently have 440 keywords of which 290 are unreserved, 50 are
column-name keywords, 23 are type-func-name keywords, and 77 are fully
reserved.  For more than 300 of those key words, the postfix operator
rule is the only thing preventing us from allowing it as a column
label without "AS".  Eliminating just those -- or even a large subset
of those -- would make things noticeably better, IMHO.

Technically, that doesn't look hard to do: (1) remove the rule that
allows postfix ops, or restrict it to operators beginning with ! or
where OPERATOR() notation is used, or whatever; (2) add a new
production target_el_keyword that includes some or all of the keywords
that don't cause grammar conflicts, (3) add a rule that target_el can
be "a expr target_el_keyword", (4) profit.  Or, since that would make
maintaining target_el_keyword a nuisance, split unreserved_keyword
into two new categories, unreserved_keyword and
very_slightly_reserved_keyword, and update elsewhere accordingly.
However, I foresee that Tom will object to the idea of creating a new
category of keywords, and I'm happy to do something else if we can
figure out what that other thing is.  I'm not immediately sure how to
use operator precedence to resolve these ambiguities; I think that for
that to work we'd have assign a precedence to every keyword that we
want to allow here, just as we currently do for IDENT.  And that seems
like it could have unforeseen side effects.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company