Re: SQL92 compliance - Mailing list pgsql-sql

From Scott Marlowe
Subject Re: SQL92 compliance
Date
Msg-id 1156357716.7223.23.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: SQL92 compliance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SQL92 compliance  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-sql
On Wed, 2006-08-23 at 12:40, Tom Lane wrote:
> 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.

Would it be possible if we required postfix operators and related to be
inside parens?

select x ~~ y as yabba
OR
select (x ~~ y) yabba

Not that I'd want that.  I prefer it the way it is too.  Just more of an
intellectual exercise.


pgsql-sql by date:

Previous
From: Emi Lu
Date:
Subject: The length of the sql query
Next
From: MHahn@seeandswim.com
Date:
Subject: All columns from table in a joined query