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

From Craig Ringer
Subject Re: [HACKERS] Make subquery alias optional in FROM clause
Date
Msg-id CAMsr+YGLuHZGeUUpTHXuP+_-Nxy8a1Yg6Mnfz2XDaGwFPZnKuA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Make subquery alias optional in FROM clause  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Make subquery alias optional in FROM clause
Re: [HACKERS] Make subquery alias optional in FROM clause
List pgsql-hackers
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.

We could reserve use of these names elsewhere, and probably should do
so to stop them leaking out if something manages to get hold of them
and re-use them via CREATE TABLE AS or something. But it seems
unlikely enough that I'm not too fussed if we don't explicitly reserve
them. Nobody is going to have a ref named "<pg anon subquery #1>"
already, I'm not concerned about BC if we do this.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Make subquery alias optional in FROM clause
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] FYI: git worktrees as replacement for "rsync the CVSROOT"