Re: [HACKERS] Questionable behavior regarding aliasing
On 10/9/15 4:16 PM, Tom Lane wrote: Jim Nasby 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 ::= [ ] ::= [ AS ] 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
Re: [HACKERS] Questionable behavior regarding aliasing
Jim Nasby 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 ::= [ ] ::= [ AS ] 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
Re: [HACKERS] 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
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
