Andrew Chernow wrote:
> 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.
>
>
Why would RedHat need to know anything at all about libpqtypes? AIUI Tom
is suggesting an API that in libpq that libpqtypes or some other library
could use, but not that libpq would be linked against libpqtypes at all.
cheers
andrew
