Re: Questionable behavior regarding aliasing

On 10/9/15 4:16 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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