Re: Questionable behavior regarding aliasing

On 10/9/15 4:16 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> I fat-fingered a view create and ended up with this:
>> ...
>>         , schemaname, relname -- other
>>         now
>>         , d_now, ...
>> I was about to report this as a bug until Marko Tiikkaja pointed out on
>> IRC that now was being treated as an alias for relname.
>
>> I'm not sure if this is required by the spec, but can we at least emit a
>> WARNING if not reject this case outright?
>
> SQL:2011 gives the syntax of a SELECT list element as
>
>      <derived column> ::=
>        <value expression> [ <as clause> ]
>      <as clause> ::=
>        [ AS ] <column name>
>
> There is not a lot of room for argument there.  And we got a lot of
> complaints back when we didn't support omitting AS.

I'm OK with omitting AS; what tripped me up was the combination of 
omitting AS *and* the next token showing up on a new line. Is there some 
reasonable way to detect that in gram.y?

Like Marko I'd be fine with a GUC for just disabling this.

> If we're going to get into the business of emitting warnings for
> required-by-SQL-spec constructs, I'm not sure that this one is
> where I'd start.  Unqualified outer references seem to catch a
> lot more people.

I'm not sure what that looks like. I always use explicit join syntax, so 
maybe that's why I've never hit it.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com