From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make subquery alias optional in FROM clause |
Date: | 2017-02-22 16:50:21 |
Message-ID: | 1487782221.2003.2.camel@oopsware.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2017-02-22 at 10:08 -0500, Tom Lane wrote:
>
> Indeed. When I wrote the comment you're referring to, quite a few
> years
> ago now, I thought that popular demand might force us to allow
> omitted
> aliases. But the demand never materialized. At this point it seems
> clear to me that there isn't really good reason to exceed the spec
> here.
> It just encourages people to write unportable SQL code.
>
Years ago i didn't hear anything about it either. But in the last few
months i've heard such a demand several times, so i thought we should
give it another try.
> > The patch generates an auto-alias for subqueries in the format
> > *SUBQUERY_<RTI>* for subqueries and *VALUES_<RTI>* for values
> > expressions. <RTI> is the range table index it gets during
> > transformRangeSubselect().
>
> This is not a solution, because it does nothing to avoid conflicts
> with
> table names elsewhere in the FROM clause. If we were going to relax
> this
> --- which, I repeat, I'm against --- we'd have to come up with
> something
> that would thumb through the whole query and make sure what it was
> generating didn't already appear somewhere else.
I've thought about this already. One thing that came into my mind was
to maintain a lookup list of aliasnames during the transform phase and
throw an ereport as soon as the generated string has any duplicate. Not
sure about the details, but i was worried about the performance impact
in this area...
> Or else not generate
> a name at all, in which case there simply wouldn't be a way to refer
> to
> the subquery by name; I'm not sure what that might break though.
>
Hmm, maybe that's an option. Though, i think parts of the code aren't
prepared to deal with empty (or even NULL) aliases. That's likely much
more invasive.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-02-22 16:52:02 | Re: pg_monitor role |
Previous Message | Magnus Hagander | 2017-02-22 16:31:19 | Re: pg_monitor role |