Re: [HACKERS] Bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: phd2(at)earthling(dot)net, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Artem Chuprina <ran(at)pirit(dot)com>
Subject: Re: [HACKERS] Bug
Date: 1999-11-30 02:28:49
Message-ID: 18882.943928929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> It appears this bug still exists.

Yes. I think this cannot be fixed without having a two-level querytree
structure for INSERT ... SELECT. The problem is basically that the
DISTINCT processing is happening on the tuples that are ready to put
into the target table (after the 'n' column is added), rather than on
the tuples that are coming out of the source table. With only one
targetlist there is no way to represent the notion that the DISTINCT
needs to happen on just the 't' column.

This is one of a large number of things waiting for a redesign of
querytrees...

regards, tom lane

>> ran=> create table test1 (n int default nextval('seq_test'), t text);
>>
>> ran=> insert into test1 ("t") select distinct src from test_source;
>>
>> ran=> select * from test1;
>> n|t
>> -+---------------
>> 1|First distinct
>> 2|First distinct
>> 3|Second distinct
>> 4|Second distinct
>> (4 rows)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-11-30 02:30:58 Re: [HACKERS] Tricky query, tricky response
Previous Message Bruce Momjian 1999-11-30 02:28:28 Re: A bug in NOT IN (SELECT ...