Re: [PATCHES] libpq type system 0.9a

Tom Lane wrote:
> Andrew Chernow <ac@esilo.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/