On Tue, Apr 15, 2008 at 11:51 AM, Alvaro Herrera <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
