Andrew Chernow wrote:
> Martijn van Oosterhout wrote:
>> How tight is the link to libpq? Could it exist as a seperate library:
>> libpqbin or something? Still in core, just only used by the people who
>> want it.
>>
>
> I gave this a lot of thought and I do think we could abstract this. The
> idea is to complie it in or out.
>
> Add a --with-typesys to configure, which could enable "#ifdef
> LIBPQ_ENABLE_TYPESYS" everywhere. If you don't specify --with-typesys,
> the API calls would still be there but would return ENOSYS, assign an
> error string or something. This preserves link capatability.
>
> This would trim out the 50k everyone is worried about :) I'm sure there
> are other ways to acocmplish this, but this one seems easiest and keeps
> it all centralized. Just like --with-openssl, except that loads
> libcrypto.so.
>
Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
(maybe a couple other places).
A separate library would remove the ability to call PQexec followed by
PQgetf because the result object is no longer aware of the typesys. You
would need the separate library to wrap the result object or something:
typesysResult = TypeSysGetResult(PQexec());
Or, you need to wrap the libpq API calls, typesysResult = TypeSysExec();.
Both are doable but not nearly as slick as: res = PQexec; PQgetf(res,
..); PQclear(res);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/