Michael Glaesemann <grzm@seespotcode.net> writes:
> On Aug 22, 2007, at 20:36 , Ben Tilly wrote:
>> I can well believe that the standard says that you must accept
>> subqueries with aliases. But does it say you must reject subqueries
>> without aliases? I strongly doubt that.
> If I'm reading my draft copy of the SQL:2003 spec right (and there's
> a good chance that I'm not, as it's not the easiest document for me
> to parse), aliases *are* required.
Yes, they are. It's been like that since SQL92 if not before (I've
never seen a copy of SQL89). I was meaning to go look up whether
SQL2003 had gotten any laxer, but thanks for saving me the trouble.
The question for us is whether we should exceed the spec by allowing
something it does not. The fundamental reason why not is that we would
have to invent an alias for the unnamed sub-select. That has several
drawbacks: more code to try to pick an unused alias, more bug reports
from people whose queries conflicted with whatever we picked. In return
for which, we're providing absolutely zip real increase in
functionality, and we're encouraging people to write unportable
SQL-spec-incompatible code. There is a future-proofing argument too:
if the committee ever decides this is a good idea (which may be unlikely
after 15 years, but you never know), they could well define the default
alias in a different way than we had done, and then we are stuck behind
the eight ball.
One could also assume that if the SQL committee has not made this
oh-so-obvious improvement, there is some darn good reason why not.
I'm not privy to their minutes so I don't know what arguments were
made there, but I think we can eliminate "they never thought of it"
as an explanation. Three generations of the spec have been written
specifically to exclude this.
In short, lots of downsides here, and not a whole lot of upside.
regards, tom lane