Re: Odd 'except' and 'default' interaction behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Clift <jclift(at)iprimus(dot)com(dot)au>
Cc: phil(at)netroedge(dot)com, pgsql-bugs(at)postgresql(dot)org, rob_fightmaster(at)ren(dot)netroedge(dot)com
Subject: Re: Odd 'except' and 'default' interaction behavior
Date: 2001-03-25 23:22:11
Message-ID: 21263.985562531@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Justin Clift <jclift(at)iprimus(dot)com(dot)au> writes:
> Can you tell me more about this strange behaviour? If it's appropriate,
> I'll try to get it onto the techdocs website.

The underlying bug is that in

INSERT INTO foo SELECT blah blah FROM bar

the INSERT processing tries to realign the SELECT's target list to match
what the INSERTed tuples need to be. This may include reordering the
values, adding NULL or default expressions for missing columns, datatype
coercions, etc.

Unfortunately the INSERT code is too stupid to know that when the SELECT
has a top-level UNION, EXCEPT, or INTERSECT operator, there are multiple
target lists that would all need to be adjusted the same way. It only
changes the first one, leading to funny errors later on.

There are other cases that break too, IIRC, mostly involving GROUP BY
or ORDER BY in the SELECT.

This is all fixed in 7.1 by the simple expedient of using two levels
of target list, so that we don't have to munge the SELECT.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Rainer Mager 2001-03-26 00:28:12 Problem with test results submission form
Previous Message Justin Clift 2001-03-25 23:10:03 Re: Various bugs with PG7.1 8th March snapshot on Solaris 8INTEL