Andrew Chernow <ac@esilo.com> writes:
> Kinda what my last suggestion was. Some tid-bits need to be reside in libpq,
> but very little. I was thinking PQtypesEnable(bool) which would dlopen
> libpqtypes and map all functions needed. This would leave the function bodies
> of PQputf, PQgetf, PQparamExec, etc... as simple proxy functions to the
> dynamically loaded functions. This removes any bloat that people don't like
> right now but still allows one to use libpq as the primary interface, rather
> than having to fiddle with libpq and some other API.
This is still 100% backwards. My idea of a libpq hook is something that
could be used by libpgtypes *and other things*. What you are proposing
is something where the entire API of the supposed add-on is hard-wired
into libpq. That's just bad design, especially when the adequacy of
the proposed API is itself in question.
When I say I'd accept some hooks into libpq, I mean some hooks that
could be used by either libpgtypes or something that would like to do
something roughly similar but with a different API offered to clients.
The particular hook that you seem to mostly need is the ability to
allocate some private memory associated with a particular PGconn object,
and maybe also with individual PGresults, and then to be able to free
that at PQclear or PQfinish. Try designing it like that.
regards, tom lane
