Re: [HACKERS] Duplicate table names
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Duplicate table names |
Дата | |
Msg-id | Pine.LNX.4.21.0002070016470.13872-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Duplicate table names (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | 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 по дате отправления: