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.