Questionable behavior regarding aliasing

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers