Re: problem (bug?) with "in (subquery)"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Luca Pireddu <luca(at)cs(dot)ualberta(dot)ca>, pgsql-sql(at)postgresql(dot)org
Subject: Re: problem (bug?) with "in (subquery)"
Date: 2005-07-15 14:58:25
Message-ID: 11560.1121439505@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> I've been reverse-engineering and simplifying this. Here's something
> that I think is close:

> CREATE TABLE foo (id integer);
> CREATE TABLE bar (id1 integer, id2 integer);

> INSERT INTO foo VALUES (1);

> INSERT INTO bar VALUES (1, 1);
> INSERT INTO bar VALUES (2, 2);
> INSERT INTO bar VALUES (3, 1);

> SELECT *
> FROM foo
> WHERE id IN (SELECT id2 FROM (SELECT DISTINCT id1, id2 FROM bar) AS s);
> id
> ----
> 1
> 1
> (2 rows)

Ah-hah: this one is the fault of create_unique_path, which quoth

/*
* If the input is a subquery whose output must be unique already, we
* don't need to do anything.
*/

Of course, that needs to read "... unique already, *and we are using all
of its output columns in our DISTINCT list*, we don't need to do
anything."

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Luca Pireddu 2005-07-15 15:52:01 Re: problem (bug?) with "in (subquery)"
Previous Message Dinesh Pandey 2005-07-15 14:38:50 Postgres for Fedora Core 2 OS ****************