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)
|
Список | 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 по дате отправления: