Обсуждение: 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

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

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

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.