Re: libpq patch for pqtypes hook api and PGresult creation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: libpq patch for pqtypes hook api and PGresult creation
Дата
Msg-id 16255.1208015520@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: libpq patch for pqtypes hook api and PGresult creation  (Andrew Chernow <ac@esilo.com>)
Ответы Re: libpq patch for pqtypes hook api and PGresult creation  (Andrew Chernow <ac@esilo.com>)
Список pgsql-patches
Andrew Chernow <ac@esilo.com> writes:
> The requirements for the connCreate hook are that the PGconn is ready
> for use.  I am currently hooking in connectDBStart, which is dead wrong.

I looked at the "object hooks" patch and it looked like a complete mess.
AFAICS the only way you could use it would be to insert hooks at library
_init() time, meaning that the mere linking of libpgtypes into an
executable would cause all your hook overhead to occur on every
connection and every query ever made by that program.  The thread
locking you put in is completely horrid as well --- you've got it
holding a process-wide lock over operations that are likely to include
nontrivial database interactions.

I think you need to consider something a bit less invasive.  What I'd
imagine is something more like this: a program that wishes to use
libpgtypes calls "PQinitTypes(PGconn *conn)" immediately after
establishing a connection, and that installs hooks into connection-local
storage and does whatever per-connection setup it needs.  No need for
any global state nor any thread mutexes.

Lastly, as far as the hook designs themselves: the "hook name" concept
seems utterly useless, and what *is* needed is missing: every callback
function needs a pass-through void * pointer so that it can get at
private state.

            regards, tom lane

В списке pgsql-patches по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Terminating a backend
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Terminating a backend