Re: "AS" by the syntax of table reference.(8.4 proposal)
От | Tom Lane |
---|---|
Тема | Re: "AS" by the syntax of table reference.(8.4 proposal) |
Дата | |
Msg-id | 4393.1202496992@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | "AS" by the syntax of table reference.(8.4 proposal) ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Список | pgsql-hackers |
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: > *** src/backend/parser/gram.y 4 Feb 2008 06:35:46 -0000 1.1 > --- src/backend/parser/gram.y 4 Feb 2008 17:24:19 -0000 1.2 > *************** > *** 8320,8325 **** > --- 8320,8333 ---- > $$->val = (Node *) $1; > $$->location = @1; > } > + | c_expr IDENT > + { > + $$ = makeNode(ResTarget); > + $$->name = $2; > + $$->indirection = NULL; > + $$->val = (Node *) $1; > + $$->location = @1; > + } > | a_expr > { > $$ = makeNode(ResTarget); Hmm, since c_expr is so restrictive, is that really going to satisfy anybody who expects to be able to omit AS? With the number of unreserved keywords we have, the restriction to IDENT for the label seems like it's going to be a constant source of gotchas as well. Both of these limitations are contrary to the SQL spec, too --- SQL99 says that a SELECT-list element is <derived column> ::= <value expression> [ <as clause> ] <as clause> ::= [ AS ] <column name> so we really need to support at least ColId as the allowed set of column alias names. (I tried changing the patch to do that, but got a lot of shift/reduce conflicts, some of which are maybe fixable but some seem hard to fix.) I think that simply saying "it's not supported" is going to be easier to deal with than people trying to use it and complaining that this or that case doesn't work. regards, tom lane
В списке pgsql-hackers по дате отправления: