Re: [SQL] SQL92 compliance
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 don't think it works for newer versions, but it should give you an idea what is required to get it working. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] SQL92 compliance
Peter Eisentraut [EMAIL PROTECTED] 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. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] SQL92 compliance
On Wed, 2006-08-23 at 12:40, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [SQL] SQL92 compliance
On Aug 23, 2006, at 10:40 , Daniel CAUNE wrote: Hi, Is AS in SELECT my_column AS my_name FROM my_table mandatory to be SQL92 compliant? You can find this in the documentation: http://www.postgresql.org/docs/8.1/interactive/sql-select.html#AEN48391 The AS Key Word In the SQL standard, the optional key word AS is just noise and can be omitted without affecting the meaning. The PostgreSQL parser requires this key word when renaming output columns because the type extensibility features lead to parsing ambiguities without it. AS is optional in FROM items, however. Hope this helps. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
