Re: Making AFTER triggers act properly in PL functions
От | Tom Lane |
---|---|
Тема | Re: Making AFTER triggers act properly in PL functions |
Дата | |
Msg-id | 23995.1094678412@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Making AFTER triggers act properly in PL functions (Stephan Szabo <sszabo@megazone.bigpanda.com>) |
Ответы |
Re: Making AFTER triggers act properly in PL functions
|
Список | 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 по дате отправления: