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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers