I wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> I think I experimented with this a while ago and found that even after
>> removing postfix operators there was at least one other grammar
>> problem that prevented us from accepting ColLabel there. I gave up
>> and didn't dig further, but maybe we should.
> Yes, it would be good to find that out.
I poked at that a little bit, by dint of changing
- | a_expr IDENT
+ | a_expr ColLabel
in the target_el production and then seeing what Bison complained about.
The majority of the problems boil down to variants of this:
state 997
1691 character: CHARACTER . opt_varying
VARYING shift, and go to state 1597
VARYING [reduce using rule 1698 (opt_varying)]
$default reduce using rule 1698 (opt_varying)
opt_varying go to state 1600
What this is telling us is that given input like, say,
SELECT 'foo'::character varying
Bison is no longer sure whether "varying" is meant as a type name modifier
or a ColLabel. And indeed there is *no* principled answer to that that
doesn't involve giving up the ability for "varying" to be a ColLabel.
Just promoting it to a fully reserved word (which it is not today)
wouldn't be enough, because right now even fully reserved words can be
ColLabels.
Another problem is here:
state 1846
1762 a_expr: a_expr ISNULL .
2418 type_func_name_keyword: ISNULL .
$end reduce using rule 1762 (a_expr)
$end [reduce using rule 2418 (type_func_name_keyword)]
pointing out that "SELECT 42 ISNULL" is now ambiguous. Since ISNULL
is nonstandard, maybe dropping support for it would be feasible.
There are some other problems that look probably fixable with
refactoring, but AFAICS the ones above are fundamental.
So we basically can't have "you can use anything at all as a ColLabel
without AS". We could probably somewhat reduce the set of words you're
not allowed to use that way, but we could not even promise that all
words that are currently unreserved would work.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
