To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-sql@postgresql.org, Daniel CAUNE <d.caune@free.fr>
Subject: Re: SQL92 compliance 
In-reply-to: <200608231811.48538.peter_e@gmx.net> 
References: <000301c6c655$0e3a0100$0b00a8c0@tedy>
	<200608231811.48538.peter_e@gmx.net>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Wed, 23 Aug 2006 18:11:47 +0200"
Date: Wed, 23 Aug 2006 13:40:16 -0400
Message-ID: <22448.1156354816@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:
> Am Mittwoch, 23. August 2006 03:40 schrieb Daniel CAUNE:
>> Is AS in "SELECT my_column AS my_name FROM my_table" mandatory to be SQL92
>> compliant?

> No.  I have a patch at 
> <http://developer.postgresql.org/~petere/select-without-as/select-without-as.patch> 
> that fixes this at least for 7.4.

I think it's a big stretch to say that that patch fixes it, since it
only allows an AS-less target expression to be c_expr rather than
a_expr as it ought to.

The problem is really insoluble given that we allow user-defined
postfix operators: is "SELECT x ~~ y" meant to be an infix operator
with arguments x and y, or a postfix operator with argument x and
a column label y?

When this has come up in the past, we've always concluded that
compliance with this not-very-well-thought-out detail of the spec
is not worth the price of giving up postfix operators.

Even if we were willing to do that, I think we'd also have to give
up using bison to generate the parser :-( because some constructs
would require more than one-token lookahead.

			regards, tom lane