Re: PostgreSQL 7.0 beta 4: Error in Insert/Select

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Shepelev <MichaelS(at)alias(dot)ru>
Cc: "'pgsql-bugs(at)postgresql(dot)org'" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: PostgreSQL 7.0 beta 4: Error in Insert/Select
Date: 2000-04-26 05:35:33
Message-ID: 15909.956727333@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Michael Shepelev <MichaelS(at)alias(dot)ru> writes:
>> I found bug (IMHO) in Insert/Select Union command.
>> Result of SELECT UNION differs from INSERT SELECT UNION.

> Wow, that's bizarre. I confirm seeing the inconsistent behavior.

On further investigation, it seems this is just another facet of the
known bogosities in INSERT ... SELECT ... UNION (see for example my
pghackers message of 7/19/99 22:59 EDT, as well as some others in the
archives). The INSERT into "o1" needs to rewrite the result of the
SELECT to include a couple of null column values, and this is being
done to the first sub-SELECT's target list *but not the second's*.
The upshot is garbage data inserted into the result table.

I looked at fixing this and concluded that trying to fix it five
days before 7.0 release would be just plain foolhardy. That part
of the code needs a thorough rewrite not emergency patches :-(
I recommend adding this example to the list of test cases for our
upcoming querytree rewrite.

In the meantime, an ugly workaround is available for Michael:
don't omit any columns in the INSERT targetlist, but instead
write explicit NULL results in the right places in the sub-SELECTs.
(Ick... but that's the best we can do for now...)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Eko Purwanto 2000-04-27 02:08:18 Bug report
Previous Message Tom Lane 2000-04-25 21:58:37 Re: