On 05/21/04:20/5, Tom Lane wrote: > Hm. I do not think you can use an expression context callback for this > anyway, because the callback won't be called in the case that query > execution is abandoned due to an error.
> What you'd need for something like that is a global data structure that > is traversed at transaction commit/abort and tells you which PyObjects > you are holding refcounts on. Indeed. I was planning to implement something along those lines for that case at a later point in time, just wasn't sure when the cleanup should occur, and how it was to be triggered at that time. I still have reservations about the temporary leakage, but I can't help but think that a "solution" to that is likely cost more than its worth. I can't imagine anything other than an explicit "end of usage" callback function stored in FmgrInfo that takes fn_extra as an argument, and this would still require ERROR handling... > You might want to look at plpgsql's > plpgsql_eoxact() function for something vaguely similar. Aye! Thanks for pointing me at EOXact! It's quite the perfect point to cleanup my fn_extra usage. I think that it is quite reasonable to specify that "inter-transaction" usage of the feature to be forbidden; thus further qualifying it as an appropriate cleanup point. Disqualifying my own idea: AFA free-hooks are concerned, it is clear to me now that they are BAD for my application, as it assumes FmgrInfo is allocated by Postgres's memory manager, and after a quick grep I see that FmgrInfo is statically declared/allocated is many places.. -- Regards, James William Pye
pgpGrvIR3fGuo.pgp
Description: PGP signature