"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
> Oops, and,
>>> so we really need to support at least ColId as the allowed set of
>>> column alias names. (I tried changing the patch to do that, but
>>> got a lot of shift/reduce conflicts, some of which are maybe fixable
>>> but some seem hard to fix.)
> Since capability was insufficient, I spent several times as many time as this.
> It understands the very hard thing. Hardship had left traces upon this features.
> I want me to still inquire.
The case that I couldn't see a good way to fix was the shift/reduce
conflicts here:
state 1414
1418 AexprConst: ConstInterval Sconst . opt_interval
DAY_P shift, and go to state 1680 HOUR_P shift, and go to state 1681 MINUTE_P shift, and go to state
1682 MONTH_P shift, and go to state 1683 SECOND_P shift, and go to state 1684 YEAR_P shift, and go to state
1685
DAY_P [reduce using rule 1149 (opt_interval)] HOUR_P [reduce using rule 1149 (opt_interval)] MINUTE_P
[reduceusing rule 1149 (opt_interval)] MONTH_P [reduce using rule 1149 (opt_interval)] SECOND_P [reduce using
rule1149 (opt_interval)] YEAR_P [reduce using rule 1149 (opt_interval)] $default reduce using rule 1149
(opt_interval)
What this is pointing out is that without AS, this statement is actually
ambiguous:
SELECT INTERVAL '1 year' YEAR;
Is "YEAR" meant to be a column alias or a qualifier for the interval
constant?
AFAICS, the only way to resolve that would be to make YEAR, as well as
the other interval qualifier words (MONTH etc), not be allowed as a
ColId ... which is per SQL spec but I confidently predict howls of
anguish from our users if we do it. I imagine there are more than
a few tables out there with columns named "month", for instance.
I guess plan B could be to rip out the special interval-constant syntax,
which we have never really implemented anyway. There isn't any
functional reason to implement it, it'd just be for spec compliance,
and you could certainly argue that supporting no-AS is more interesting
than supporting interval-constant qualifiers.
The other conflicts I saw could be resolved by making a small number
of other keywords like CHARACTER and VARYING reserved (or more reserved
than they are now anyway). These seemed like they'd be less of a
problem to reserve than the interval qualifier words.
However that still leaves us with the problem that c_expr isn't flexible
enough to make this spec-compliant. AFAICS the only way to fix that is
to give up postfix operators. IMHO, an actual loss of functionality is
too high a price to pay for being able to omit AS.
regards, tom lane