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

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: "AS" by the syntax of table reference.(8.4 proposal)
Дата
Msg-id 878x1tluri.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: "AS" by the syntax of table reference.(8.4 proposal)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: "AS" by the syntax of table reference.(8.4 proposal)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "AS" by the syntax of table reference.(8.4 proposal)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "AS" by the syntax of table reference.(8.4 proposal)