Re: Better support for whole-row operations and composite - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Better support for whole-row operations and composite
Date
Msg-id 406F4344.8060301@joeconway.com
Whole thread Raw
In response to Re: Better support for whole-row operations and composite  (Joe Conway <mail@joeconway.com>)
Responses Re: Better support for whole-row operations and composite  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Joe Conway wrote:
> Given the above changes, it's almost working now -- only problem left is 
> with triggers:
> 
> 
>   insert into foo values(11,'cat99',1.89);
> + ERROR:  record type has not been registered
> + CONTEXT:  In PL/R function rejectfoo
> 
>   delete from foo;
> + ERROR:  cache lookup failed for type 0
> + CONTEXT:  In PL/R function rejectfoo
> 
> (and a few other similar failures)
> 
> Any ideas why the trigger tuple type isn't registered, or what I'm doing 
> wrong?

A little more info on this. It appears that the tuple type is set to 
either 2249 (RECORDOID) or 0. In the case of RECORDOID this traces all 
the way back to here:

/* ---------------------------------------------------------------- *   CreateTemplateTupleDesc * *   This function
allocatesand zeros a tuple descriptor structure. * *   Tuple type ID information is initially set for an anonymous
record*   type; caller can overwrite this if needed. * ----------------------------------------------------------------
*/

But the type id is never overwritten for a BEFORE INSERT trigger. It 
appears that somewhere it is explictly set to InvalidOid for both BEFORE 
DELETE and AFTER INSERT triggers (and possibly others). My take is that 
we now need to explicitly set the tuple type id for INSERT/UPDATE/DELETE 
statements -- not sure where the best place to do that is though. Does 
this sound correct?

Joe



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Inconsistent behavior on Array & Is Null?
Next
From: Josh Berkus
Date:
Subject: Re: Function to kill backend