Re: [HACKERS] Duplicate table names - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] Duplicate table names
Date
Msg-id Pine.LNX.4.21.0002070016470.13872-100000@localhost.localdomain
Whole thread Raw
In response to Duplicate table names  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
On 2000-02-06, Thomas Lockhart mentioned:

> The following query is rejected (and always has been afaik):
> 
> select * from t1, t1;
> 
> Does this rejection have any basis in SQL92? (I haven't looked; hoping
> someone else has.)

Not according to the way I decoded it. It's a join of t1 with itself and
you get all columns twice.

> 
> istm that
> 
> select x from t1, t1;
> 
> would have trouble, but the wildcard could do the Right Thing even

This is the same problem as

select x from t1, t2;

where both t1 and t2 have a column x. It's an error. It's not an error if
column x is unambiguous. Chances are pretty good (=100%) that there will
be ambiguity if you list the same table twice, but there's no reason to
reject this for the reason it gives now.

[snip]
> I'm thinking of implementing this by allowing multiple RTEs to have
> the *same* table alias, (as long as there aren't column name conflicts
> in the "visible" columns), so that, at least internally,
> 
> select * from t1 tx, t3 tx;
> 
> becomes legal as long as t1 and t3 do not share common column names.

This seems perfectly legal as well, even if they do share column names.
Any reference to tx.y will fail due to ambiguity, but it shouldn't merely
because of name checking.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: [HACKERS] ONLY
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] psql -e and -n flags