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
|
Список | 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 по дате отправления: