Re: libpq patch for pqtypes hook api and PGresult creation - Mailing list pgsql-patches

From Tom Lane
Subject Re: libpq patch for pqtypes hook api and PGresult creation
Date
Msg-id 16255.1208015520@sss.pgh.pa.us
Whole thread Raw
In response to Re: libpq patch for pqtypes hook api and PGresult creation  (Andrew Chernow <ac@esilo.com>)
Responses Re: libpq patch for pqtypes hook api and PGresult creation  (Andrew Chernow <ac@esilo.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Terminating a backend
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Terminating a backend