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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
