Re: [HACKERS] Questionable behavior regarding aliasing

2015-10-09 Thread Marko Tiikkaja

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


Re: [HACKERS] Questionable behavior regarding aliasing

2015-10-09 Thread Jim Nasby

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

2015-10-09 Thread Tom Lane
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


[HACKERS] Questionable behavior regarding aliasing

2015-10-09 Thread Jim Nasby

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