Thread: Shorthand column labels (SELECT col1 foo, ...) vs (SELECT col1 AS foo, ...)
I notice PG doesn't allow shorthand column labels -- it requires the 'AS' operand. SELECT col1 foo, ...; -> ERROR: syntax error at or near "foo" For compatibility with other databases, what objections might be argued in allowing this syntax in the future? On the 'pros' side I think it eases migration to PG, shortens code, is similar syntax to shorthand table aliases, and some users might argue it has become defacto syntax among DBs. Regards, Ken
Re: Shorthand column labels (SELECT col1 foo, ...) vs (SELECT col1 AS foo, ...)
From
Paul Lambert
Date:
Ken Johanson wrote: > I notice PG doesn't allow shorthand column labels -- it requires the > 'AS' operand. > > SELECT col1 foo, ...; -> ERROR: syntax error at or near "foo" > > For compatibility with other databases, what objections might be argued > in allowing this syntax in the future? > > On the 'pros' side I think it eases migration to PG, shortens code, is > similar syntax to shorthand table aliases, and some users might argue it > has become defacto syntax among DBs. > > Regards, > Ken Briefly discussed a couple of weeks ago. See http://archives.postgresql.org/pgsql-general/2008-01/msg00089.php
Re: Shorthand column labels (SELECT col1 foo, ...) vs (SELECT col1 AS foo, ...)
From
Ken Johanson
Date:
Paul Lambert wrote: > Ken Johanson wrote: >> I notice PG doesn't allow shorthand column labels -- it requires the >> 'AS' operand. >> >> SELECT col1 foo, ...; -> ERROR: syntax error at or near "foo" > > Briefly discussed a couple of weeks ago. > > See http://archives.postgresql.org/pgsql-general/2008-01/msg00089.php > Interesting thread(s)! What I didn't see discussed was the possibility of making a server and/or session option, where we could elect to turn-off the old behavior (PG specific behavior) and enable the standard/shorthand syntax. Users need a migration path. I personally cant ever see using those PGisms/features and would choose to enable the standard mode. I think I'd have fewer compatibility problems. Ken
Re: Shorthand column labels (SELECT col1 foo, ...) vs (SELECT col1 AS foo, ...)
From
Paul Lambert
Date:
Ken Johanson wrote: > Interesting thread(s)! > > What I didn't see discussed was the possibility of making a server > and/or session option, where we could elect to turn-off the old behavior > (PG specific behavior) and enable the standard/shorthand syntax. Users > need a migration path. > > I personally cant ever see using those PGisms/features and would choose > to enable the standard mode. I think I'd have fewer compatibility problems. > > Ken What was discussed is that the AS keyword is required because of the way the interpreter parses the commands. With the example given, how does it know that 1::character varying isn't casting to a character field with an alias of varying or a character varying field with no alias? If there was simply a switch to turn the requirement on or off that's not going to stop things from breaking - the postfix operators still need to be picked up somehow, it's a technical limitation rather than a "let's just be difficult and be incompatible with other dbms's" limitation I think it would be nice as well, I had to migrate a system that didn't bother putting AS in any of it's views/stored procedures etc and went through this pain - but I think having to change everything was worth it to make sure all my scripts were correctly written and free from possible misinterpretation. My thoughts anyway.