Re: [HACKERS] Bug - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Bug
Date
Msg-id 18882.943928929@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Bug  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Tricky query, tricky response
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] union and LIMIT problem