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
