Andrew Chernow wrote:
>>
>> 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
Your method would work as well. The only issue is you still have the
same issue of binary distributed libpqs. Would redhat distribute a
binary linked with libpqtypes? If not, you have the same issue of the
end-user having to compile libpq ... passing -lpqtypes to the linker.
If redhat did link it, you run into the disk space complaint all over again.
My suggestion was trying to work around this by dynamically loading the
library, PQtypesEnable(TRUE). In this model, redhat doesn't even have
to distribute libpqtypes.so (considering the disk space issue). It
could be easily be an additional download. All you need are some proxy
functions inside libpq, PQputf calling a dynamically loaded function.
This passes the disk space complaints and doesn't require a re-compile
if an end-user wants to use it.
Andrew
