Re: Clean-up callbacks for non-SR functions

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Clean-up callbacks for non-SR functions
Дата
в 14:36:01
Msg-id
10556.1085160939@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Clean-up callbacks for non-SR functions James William Pye <flaw@rhid.com>
Re: Clean-up callbacks for non-SR functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Clean-up callbacks for non-SR functions James William Pye <flaw@rhid.com>
Re: Clean-up callbacks for non-SR functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Clean-up callbacks for non-SR functions James William Pye <flaw@rhid.com>
Re: Clean-up callbacks for non-SR functions Tom Lane <tgl@sss.pgh.pa.us>
Re: Clean-up callbacks for non-SR functions James William Pye <flaw@rhid.com>
James William Pye  writes:
> On 05/20/04:20/4, Tom Lane wrote:
>> It's true that this setup doesn't allow non-SRFs to get at the econtext,
>> but I'm not sure that they need to.

> The only thing my goal has in common with getting at the econtext is
> the ability to register a callback that can clean up my fn_extra at a
> relatively appropriate time.

> Effectively, the looked-up FmgrInfo "owns" a reference to the PyObject*
> stored in fn_extra. Ideally, the reference count of the object that fn_extra
> points to would be decremented by a callback/hook before the FmgrInfo is
> destroyed/pfree'd..

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.  You might want to look at plpgsql's
plpgsql_eoxact() function for something vaguely similar.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: Matthew T. O'Connor
Дата:
FAQ