Re: Relax table alias conflict rule in 9.3?

From: Andreas <maps(dot)on(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Relax table alias conflict rule in 9.3?
Date: 2013-11-12 23:56:24
Message-ID: 5282C028.9050602@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Am 11.11.2013 02:06, schrieb Tom Lane:
> We had a complaint
> http://www.postgresql.org/message-id/E1VJuBy-0002a1-Qv@wrigleys.postgresql.org
> about the fact that 9.3 rejects queries with duplicate table aliases like
> this:
>
> select * from tenk1 a left join (int4_tbl a cross join int8_tbl b) c on unique1 = f1;
> ERROR: table name "a" specified more than once
>
> I pushed back on this on the grounds that this is illegal per SQL spec:
> the standard is pretty clear that you can't use the same table alias more
> than once in a given level of SELECT (cf SQL:2008 7.6 <table reference>,
> syntax rules 6 and 7). However, the complainant has a good point that if
> we've accepted this since forever, ceasing to accept it is going to cause
> people problems. Moreover, my argument that it makes things ambiguous for
> LATERAL doesn't hold a lot of water. Duplicate table aliases were
> potentially ambiguous before, too, but we allowed the case anyway and only
> complained if there's actually an ambiguous reference. We could do the
> same for LATERAL references.
> [...]
>
> So I propose removing that call, adding regression tests like these
> examples, and back-patching to 9.3. Any objections?
>
> regards, tom lane
>

Great! :)

This change would help me upgrade to 9.3x because I've got lots of views
that use a table alias that gets rejected by 9.3 while restoring the
dump of 9.2.

When do you plan to have it in an official release?

Cheers
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2013-11-13 00:11:08 Re: Clang 3.3 Analyzer Results
Previous Message Tomas Vondra 2013-11-12 23:52:01 Re: FDW: possible resjunk columns in AddForeignUpdateTargets