Re: Making AFTER triggers act properly in PL functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making AFTER triggers act properly in PL functions
Date
Msg-id 23995.1094678412@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making AFTER triggers act properly in PL functions  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Responses Re: Making AFTER triggers act properly in PL functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> I think the main concern here would be the space cost of
>> adding still another field to the trigger records ... is it worth it?

> Would it be possible to basically alias the space for dte_done_xid to hold
> either the xid if it's done or the <whatever> if it's in progress? That's
> ugly, but it would presumably not increase the size of the record.

Yeah, I was wondering the same, but hadn't quite worked out the details.
The difficulty is that if trigger execution is abandoned due to an
error, you'd have to be able to recognize which entries weren't really
"in progress" anymore.  If the values aren't XIDs, I'm not sure how to
do that.

One thing I was looking at was that we aren't using nearly all the bits
of dti_state.  It'd be possible to narrow that to int16 and then
shoehorn a 16-bit query nesting depth counter into the freed space.
Not sure if this is enough though.

Actually, I'd really like to get it back down to the 7.4 size, which was
already too big :-(.  That might be a vain hope though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Geometry regression test failure, CVS HEAD, Mac OS/X
Next
From: Tom Lane
Date:
Subject: Re: Geometry regression test failure, CVS HEAD, Mac OS/X