----- Original Message -----
From: "Tom Lane" <[EMAIL PROTECTED]>
"Hiroshi Saito" <[EMAIL PROTECTED]> 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:
Eh?, c_expr IDENT is no conflicts....?_?
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 [reduce using rule 1149 (opt_interval)]
MONTH_P [reduce using rule 1149 (opt_interval)]
SECOND_P [reduce using rule 1149 (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?
postgres=# SELECT INTERVAL '1 year' YEAR;
interval
----------
1 year
(1 row)
Sorry, please let me read the following sentences later.
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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
