Re: [HACKERS] Make subquery alias optional in FROM clause - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Make subquery alias optional in FROM clause
Date
Msg-id CA+TgmoZ+TnTTptqBNnZvg5seAraNpxsxhWyJY5r4qnFW-i0+sw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Make subquery alias optional in FROM clause  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Fri, Feb 24, 2017 at 1:04 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 23 February 2017 at 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> * Don't force/generate an alias at all.
>>
>>> I've no idea for this yet and Tom already was concerned what this might
>>> break. There are several places in the transform phase where the
>>> refnames are required (e.g. isLockedRefname()).
>>
>> Yeah.  This would be cleaner in some sense but also a lot more delicate.
>> Not sure it's worth the trouble.
>
> Personally I think we need to generate one, if nothing else for error
> messages where we try to emit qualified names of columns.
>
> But I don't see that the name needs to be anything we can refer to
> elsewhere or anything faintly sane to type. Something like:
>
>   "<pg anon subquery #[counter]>"
>
> in line with our current generation of refcursor names.

Isn't that a terribly unfriendly thing to include in an error message?I'd much rather see the column qualified with
whateverthe alias name
 
is inside the subquery than see it qualified with some internally
generated name that's completely meaningless.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Proposal : Parallel Merge Join