Re: [HACKERS] Make subquery alias optional in FROM clause
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Make subquery alias optional in FROM clause |
Дата | |
Msg-id | CA+TgmobCrKvjvRruwVz0QOpuNEMh7fqGxcY+fkP=jiUwo5g6XQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Make subquery alias optional in FROM clause (Pantelis Theodosiou <ypercube@gmail.com>) |
Ответы |
Re: [HACKERS] Make subquery alias optional in FROM clause
|
Список | pgsql-hackers |
On Thu, Feb 23, 2017 at 4:08 PM, Pantelis Theodosiou <ypercube@gmail.com> wrote: > Question: Will the patch be removed if and when Oracle decides to be > compatible with the standard and forbids non-aliased derived tables? > > (I know it's a rather theoretical question. Unlikely that Oracle breaks > backwards compatibility on that.) Even if they did, so what? First of all, our project's aim is not to copy Oracle slavishly but to build a good database. Sometimes that involves making things work in ways similar to Oracle and sometimes it doesn't. For example, I have no urge to get rid of transactional DDL just because Oracle doesn't have it. I have no feeling that NULL should behave in the completely unprincipled way that it does in Oracle. And I don't think that PostGIS needs to try to go be more like Oracle Spatial. Secondly, extensions to the standard that let reasonable things work which the standard doesn't permit are generally a good idea. We don't want to let things work that really deserve to fail - for example because the meaning is ambiguous - nor do we want to implement standard syntax with non-standard semantics. However, neither of those problems exists for this case. I don't see the point in making things fail that could just as easily do what was wanted; that seems pedantic. I don't think it's only Oracle that allows omitting the alias; I think there are a number of other systems that behave similarly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: