Message-ID: <4785D174.4030203@optusnet.com.au>
Date: Thu, 10 Jan 2008 17:04:04 +0900
From: Paul Lambert <plengada@optusnet.com.au>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ken Johanson <pg-user@kensystem.com>
CC: pgsql-sql@postgresql.org
Subject: Re: Shorthand column labels (SELECT col1 foo, ...) vs (SELECT
	col1 AS foo, ...)
References: <4785C50F.6010505@kensystem.com>
 <4785C744.6080406@optusnet.com.au>
	<4785CBE9.6000108@kensystem.com>
In-Reply-To: <4785CBE9.6000108@kensystem.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.