Re: "AS" by the syntax of table reference.(8.4 proposal)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "AS" by the syntax of table reference.(8.4 proposal)
Date: 2008-02-08 21:33:55
Message-ID: 6650.1202506435@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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 [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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-02-08 22:15:55 Re: "AS" by the syntax of table reference.(8.4 proposal)
Previous Message Alvaro Herrera 2008-02-08 20:01:43 Re: pg_dump additional options for performance