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