Re: pulling libpqtypes from queue

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/