Re: [HACKERS] Make subquery alias optional in FROM clause

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Make subquery alias optional in FROM clause
Дата
Msg-id 24338.1487776118@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] Make subquery alias optional in FROM clause  (Bernd Helmle <mailings@oopsware.de>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Replication vs. float timestamps is a disaster
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Replication vs. float timestamps is a disaster