Re: [PATCHES] libpq type system 0.9a

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