Re: SQL feature requests - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: SQL feature requests
Date
Msg-id 200708240017.21596.peter_e@gmx.net
Whole thread Raw
In response to Re: SQL feature requests  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: SQL feature requests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Florian G. Pflug wrote:
> knowing *why* the standard committee disallows that syntax -
> and why everybody except oracle chose to agree with it would be quite
> interesting.

Consider that we rightfully disallow

SELECT * FROM tab1, tab1;

because there are two tables with the same name involved.  This hints to 
the fact that the internal query processing needs to have a unique name 
for each table source.  You could argue why that would have to be, but 
it seems quite useful.  Otherwise you would also have to allow

SELECT * FROM tab1 AS a, tab2 AS a;

and that cannot possibly be good.

If you believe that, then a table source without any name at all, such 
as one produced by subqueries, should also be disallowed.  Requiring a 
unique name appears to be a stronger condition than requiring a name at 
all.  This is actually false if you consider that SQL itself does 
distinguish between unique constraints and not-null constraints.  But 
you don't really want to invent a logic by which nameless table sources 
are managed.  Strict logic would probably require the results of all 
such queries to be unknown.

Note that Oracle is notorious for mishandling null values in various 
ways.  So it's not surprising that they mishandle "null" table names in 
what appears to be pretty much the same way.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Joining the PostgreSQL build farm
Next
From: Manuel Sugawara
Date:
Subject: Segmentation fault using digest from pg_crypto