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

From Tom Lane
Subject Re: [HACKERS] Make subquery alias optional in FROM clause
Date
Msg-id 24338.1487776118@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Make subquery alias optional in FROM clause  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: [HACKERS] Make subquery alias optional in FROM clause  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [HACKERS] Make subquery alias optional in FROM clause  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [HACKERS] Make subquery alias optional in FROM clause  (Bernd Helmle <mailings@oopsware.de>)
Re: [HACKERS] Make subquery alias optional in FROM clause  (Nico Williams <nico@cryptonector.com>)
Re: [HACKERS] Make subquery alias optional in FROM clause  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Bernd Helmle <mailings@oopsware.de> writes:
>> From time to time, especially during migration projects from Oracle to
> PostgreSQL, i'm faced with people questioning why the alias in the FROM
> clause for subqueries in PostgreSQL is mandatory. The default answer
> here is, the SQL standard requires it.

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.

> 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.  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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster