From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Fuhr <mike@fuhr.org>
Cc: Luca Pireddu <luca@cs.ualberta.ca>
Cc: pgsql-sql@postgresql.org
Subject: Re: problem (bug?) with "in (subquery)"
Date: Fri, 15 Jul 2005 10:58:25 -0400
Message-ID: <11560.1121439505@sss.pgh.pa.us> (raw)
In-Reply-To: <20050715141037.GA30461@winnie.fuhr.org>
References: <200507140134.21133.luca@cs.ualberta.ca>
<10971.1121435967@sss.pgh.pa.us>
<20050715141037.GA30461@winnie.fuhr.org>
Michael Fuhr <mike@fuhr.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, mike@fuhr.org, luca@cs.ualberta.ca
Subject: Re: problem (bug?) with "in (subquery)"
In-Reply-To: <11560.1121439505@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox