Re: [HACKERS] Duplicate table names

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Postgres Hackers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Duplicate table names
Date: 2000-02-07 21:03:01
Message-ID: 3.0.1.32.20000207130301.0109a750@mail.pacifier.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 12:26 PM 2/7/00 -0800, Don Baccus wrote:

>>> 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.

>Actually, according to Date an explicit range variable must be
>unique within a given scope.

I consulted the Oracle, and it agrees with Peter, hmmm...and the
wording in Date's a bit ambiguous, he's not clear as to whether
the range variable must be unique when DEFINED, or must only be
unique if it is referenced, i.e. select tx.foo from t1 tx, t3 tx
is ambiguous.

Reading further into Date, he says that

select ... from t1

implicitly defines t1 as a range variable, and since

select ... from t1, t1 is legal, then range variables need not be
unique to be defined, 'cause according to the standard this
causes two range variables named t1 to be implicitly defined.

So, his comment about uniqueness within scope applies to whether
or not you can explicitly REFERENCE, not DEFINE the range var.

Sorry for the confusion...Peter was right all along.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-02-07 21:03:10 Re: [HACKERS] network_ops in 7.0 and pg_dump question
Previous Message Hannu Krosing 2000-02-07 20:53:29 Re: [HACKERS] An introduction and a plea ...