Re: pulling libpqtypes from queue

On Tue, Apr 15, 2008 at 11:51 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Andrew Chernow escribió:
> > Maybe we'll get enough support in the future to get our stubs into core.
> > Until then, you'll have to patch libpq. We plan to provide binary
> > patches for the major platforms. You won't have to patch the guts of
> > pqtypes though because that is dynamically loaded behind PQtypesLoad ...
> > you just need libpqtypes.[so|dll] in your libpath.
>
> Requiring your users to patch libpq is not going to gain libpqtypes much
> acceptance. It would be far better if it can be enabled by just calling
> some additional function in the application code (after requiring the
> app to link with pqtypes of course). This additional function would
> set up pqtypes for later use.
>
> I don't really see the problem you got with the hooks.

You are quite right that it will be easier for people to try the thing
out without having use a custom libpq. So, we will submit an updated
libpq hooks patch to -patches. If you think it's possible for this to
get through, we can pursue it (we were starting to become skeptical).
We are flexible on this.

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