Re: Allow an alias to be attached directly to a JOIN ... USING

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow an alias to be attached directly to a JOIN ... USING
Date: 2020-01-27 09:19:51
Message-ID: d173356b-8ee7-8036-0f17-04d196494143@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-12-31 00:07, Vik Fearing wrote:
> One thing I notice is that the joined columns are still accessible from
> their respective table names when they should not be per spec.  That
> might be one of those "silly restrictions" that we choose to ignore, but
> it should probably be noted somewhere, at the very least in a code
> comment if not in user documentation. (This is my reading of SQL:2016 SR
> 11.a.i)

Here is a rebased patch.

The above comment is valid. One reason I didn't implement it is that it
would create inconsistencies with existing behavior, which is already
nonstandard.

For example,

create table a (id int, a1 int, a2 int);
create table b (id int, b2 int, b3 int);

makes

select a.id from a join b using (id);

invalid. Adding an explicit alias for the common column names doesn't
change that semantically, because an implicit alias also exists if an
explicit one isn't specified.

I agree that some documentation would be in order if we decide to leave
it like this.

Another reason was that it seemed "impossible" to implement it before
Tom's recent refactoring of the parse namespace handling. Now we also
have parse namespace columns tracked separately from range table
entries, so it appears that this would be possible. If we want to do it.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v3-0001-Allow-an-alias-to-be-attached-to-a-JOIN-.-USING.patch text/plain 25.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-01-27 09:38:13 Re: [Proposal] Global temporary tables
Previous Message Konstantin Knizhnik 2020-01-27 09:11:29 Re: [Proposal] Global temporary tables