From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: column aliases |
Date: | 2000-06-08 02:55:43 |
Message-ID: | 200006080255.WAA09541@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Did this get resolved somehow?
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > test=> select * from pg_language p where p.oid = pg_language.oid;
> > lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
> > ----------+---------+--------------+---------------+-------------
> > internal | f | f | 0 | n/a
> > C | f | f | 0 | /bin/cc
> > sql | f | f | 0 | postgres
> > (3 rows)
>
> Oh, this is interesting! According to Postgres' view of the world,
> you have written a join between "pg_language p" and
> "pg_language pg_language", where the latter is an implicitly added
> FROM clause. If you do an EXPLAIN you can see that a join is indeed
> being done:
>
> regression=# explain
> regression-# select * from pg_language p where p.oid = pg_language.oid;
> NOTICE: QUERY PLAN:
>
> Hash Join (cost=2.60 rows=4 width=58)
> -> Seq Scan on pg_language p (cost=1.13 rows=4 width=54)
> -> Hash (cost=1.13 rows=4 width=4)
> -> Seq Scan on pg_language (cost=1.13 rows=4 width=4)
>
> EXPLAIN
>
> and a more graphic demonstration is had by using a WHERE clause that
> can produce multiple matches:
>
> regression=# select * from pg_language p where p.oid < pg_language.oid;
> lanname | lanispl | lanpltrusted | lanplcallfoid | lancompiler
> ----------+---------+--------------+---------------+-------------
> internal | f | f | 0 | n/a
> internal | f | f | 0 | n/a
> C | f | f | 0 | /bin/cc
> internal | f | f | 0 | n/a
> C | f | f | 0 | /bin/cc
> sql | f | f | 0 | postgres
> (6 rows)
>
> What it looks like to me is that we have a bug in the expansion of '*'.
> It should be generating columns for both the explicit and the implicit
> FROM clause, but it's evidently deciding that it should only produce
> output columns for the first one.
>
> This may go a long way towards explaining why people have been so
> readily confused by the implicit-FROM-clause business! If they saw
> two sets of columns coming out, it'd be more obvious that they were
> getting a join.
>
> > Does the standard say the first query is legal?
>
> I believe it is not strict SQL92 --- we've been around on that question
> before.
>
> regards, tom lane
>
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-08 02:57:14 | Re: Implementing STDDEV and VARIANCE |
Previous Message | Tom Lane | 2000-06-08 02:43:50 | Re: Apparent deadlock 7.0.1 |