Re: [SQL] CHECK problem really OK now...

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kovacs Baldvin <kb136@hszk.bme.hu>
Cc: Jan Wieck <JanWieck@Yahoo.com>, Kevin Way <kevin.way@overtone.org>, pgsql-sql@postgresql.org, pgsql-hackers@postgresql.org
Date: 2001-09-26T18:36:58Z
Lists: pgsql-hackers, pgsql-general, pgsql-sql
Kovacs Baldvin <kb136@hszk.bme.hu> writes:
> I tried, and it works: the current CVS version really runs
> happily the query what sent to heaven our 7.1 version of the
> backend.

I believe this traces to a fix I made in May:

2001-05-27 16:48  tgl

	* src/: backend/executor/execJunk.c, backend/executor/execMain.c,
	include/executor/executor.h, include/nodes/execnodes.h: When using
	a junkfilter, the output tuple should NOT be stored back into the
	same tuple slot that the raw tuple came from, because that slot has
	the wrong tuple descriptor.  Store it into its own slot with the
	correct descriptor, instead.  This repairs problems with SPI
	functions seeing inappropriate tuple descriptors --- for example,
	plpgsql code failing to cope with SELECT FOR UPDATE.

I didn't realize at the time that the error would also affect updates of
child tables, but tracing through your example with 7.1 shows clearly
that the CHECK is being applied to a slot that contains a four-column
tuple and only a three-column descriptor.  Ooops.

			regards, tom lane