From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "tudorb(at)gmail(dot)com" <tudorb(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15088: Can create subquery with duplicate column names |
Date: | 2018-02-26 01:20:13 |
Message-ID: | CAKFQuwa74o+ZTe6mhY3bRRqdMa6kup8gfnzaudzF96wFEZYGpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sunday, February 25, 2018, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 15088
> Logged by: Tudor Bosman
> Email address: tudorb(at)gmail(dot)com
> PostgreSQL version: 9.5.11
> Operating system: Ubuntu 16.04
> Description:
>
> This may not be a bug, but you can create a subquery that has ambiguous
> column names, and then you have no way to disambiguate between them, as the
> originating table names are no longer in scope.
>
>
> [...]
> ... and the result now has two columns named x, and I can't tell them
> apart:
>
>
That is correct, though with a result you (in client software) can target a
column number in lieu of a name so all hope is not lost. PostgreSQL won't
let you create table or create view from such a result though, only a
result set.
At this point backward compatibility will prevent changing the behavior
regardless of its individual merit. And its (usually) obvious and easy to
fix if you do get presented with said error.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Clough | 2018-02-26 09:04:43 | RE: BUG #15067: Documentation or behaviour bug with autovacuum thresholds? |
Previous Message | Tomas Vondra | 2018-02-26 00:54:01 | Re: BUG #15088: Can create subquery with duplicate column names |