Re: "AS" by the syntax of table reference.(8.4 proposal) - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: "AS" by the syntax of table reference.(8.4 proposal)
Date
Msg-id 878x1tluri.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: "AS" by the syntax of table reference.(8.4 proposal)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "AS" by the syntax of table reference.(8.4 proposal)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> Sure, just like a + + b is ambiguous. We define an arbitrary choice and tell
>> people to put parentheses if they want the other. It's not too hard to write
>> SELECT (a +) b, ...
>> if you want an alias. Besides, nobody uses postfix expressions anyways. It
>> would be a pain if it worked the other way and you had to write (a + b) all
>> the time.
>
> Hm, well, now that you mention it we already have provisions to
> discriminate against the postfix-op case when things are ambiguous.
> So really this is a precedence problem, which leads to the attached
> proposal for a patch.  This still has the problem of only allowing
> IDENT for AS-less column labels, but at least it avoids restricting
> the expression.

Well as I said before, I'm for including it even if it only works for IDENT. I
think that's good enough to be worth including.

Of course it would still be better if we could get it closer to ColId. YEAR
MONTH DAY HOUR MINUTE SECOND the only problem spots? How much else had to
change to work around other conflicts?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "AS" by the syntax of table reference.(8.4 proposal)
Next
From: Tom Lane
Date:
Subject: Re: "AS" by the syntax of table reference.(8.4 proposal)