Merlin Moncure wrote:
>
> For posterity, here are our objections to hooking libpq:
> *) Is there any other plausible scenario of another use for hooking
> into libpq events? (this is rhetorical...we don't think there is.) We
> think that there is a better way to integrate libpqtypes with libpq so
> maybe the abstraction is unnecessary.
> *) keeping PQparamExec & friends outside of libpq makes error handling
> a little awkward...we expect to use TLS errors in libpqtypes (which,
> quite frankly, I wish libpq used) but think it would be cleaner to
> handle errors in consistent fashion with libpq...libpqtypes adds
> PQseterror, PQgeterror.
> *) We especially don't like having to explicitly install into every
> PGconn (PQaddObjectHooks). So, an app that wants to be ported to
> using PQgetf for example, needs to locate and inject code into all
> places connections are made, rather than just inject the call. We
> would rather have things just 'work'.
> *) In the event pqtypes becomes popular, will it remain a hooked
> library forever? If not (a tighter integration that we are advocating
> takes place), then we are stuck with the 'hook' api functions forever,
> unless this happens before 8.4 gets out.
>
> merlin
>
>
Installing it per-conn doesn't get you anything. pqtypes has already
been linked in. If you use PQexec and PQgetvalue, the pqtypes code
pretty much does nothing. So, a per-conn install seems redundant. You
are installing the same function pointers under the same name over and
over. If you link with, it should just be available.
#include <libpqtypes.h>
// library-wide init
PQtypesInit(void);
// libpqtypes is ready for use on any conn
That is what we would prefer. We tried to do it with a global array and
a lock, but that has its own problems (namely, all the locking).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
