From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] libpq type system 0.9a |
Date: | 2008-04-08 22:09:13 |
Message-ID: | 47FBED09.1090304@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
> Andrew Chernow <ac(at)esilo(dot)com> writes:
>>> I gave this a lot of thought and I do think we could abstract this. The
>>> idea is to complie it in or out.
>
> [shrug...] So the packagers will compile it out, and you're still hosed,
> or at least any users who'd like to use it are.
>
>> Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
>> (maybe a couple other places).
>
> I didn't see anything there that seemed that it *had* to be inside
> libpq, and certainly not anything that couldn't be handled with a
> small hook or two.
>
> regards, tom lane
>
How about using dlopen and dlsym?
Sseparate the library as many are suggesting. But leave the functions, the
tid-bits in PGconn, PGresult, etc... in there (2 or 3 typedefs would be needed
but all data-type typedefs "PGtimestamp" can be removed). You need something
inside the PGconn and PGresult, even if just a function pointer that gets called
if not NULL.
Yank pqtypes function bodies, and related helper functions, and replace them
with something like below:
int PQputf(...)
{
#ifdef HAVE_DLOPEN
if(pqtypes->putf)
return pqtypes->putf(...);
return 1; /* failed, PGparam error = "not enabled" */
#else
return 1; /* failed, PGparam error = "cannot load dynamically" */
#endif
}
Then add a PQtypesEnable(bool), which would dlopen(libpqtypes) and dlsym the 10
functions or so we need. Any typedefs you need would be in libpqtypes.h rather
than libpq-fe.h. You could disable it as well, which would unload libpqtypes.
The default would obviously be disabled.
The entire patch would be one small file with a couple 1 line changes to PGconn
and PGresult. This would remove all overhead, at least 95% of it.
>>couldn't be handled with a small hook or two.
Maybe, have not thought of that. The problem, is that I am trying to make avoid
having to keep track of two different APIs. The goal is the libpq user is
coding to the libpq API, not some other API like PGTypesExec.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-04-08 22:09:23 | Re: [PATCHES] libpq type system 0.9a |
Previous Message | Alvaro Herrera | 2008-04-08 22:07:56 | Re: [PATCHES] libpq type system 0.9a |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-04-08 22:09:23 | Re: [PATCHES] libpq type system 0.9a |
Previous Message | Alvaro Herrera | 2008-04-08 22:07:56 | Re: [PATCHES] libpq type system 0.9a |