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