Обсуждение: Questionable behavior regarding aliasing

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? I think it'd be OK to leave 
the AS syntax alone... presumably it's a lot harder to fumble that. But 
I'm not wed to that.
-- 
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

On 2015-10-09 10:31 PM, Jim Nasby wrote:
> 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? I think it'd be OK to leave
> the AS syntax alone... presumably it's a lot harder to fumble that. But
> I'm not wed to that.

I'd be happy to turn on a GUC disabling this misfeature.  It's only ever 
brought pain and unhappiness to me and my family.


.m

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.

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.
        regards, tom lane

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