Re: [PATCHES] libpq type system 0.9a

On Tue, Apr 8, 2008 at 6:09 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Andrew Chernow wrote:
>
> > Forgot to say: There is stuff in PGconn, PGresult, PQclear, PQfinish
> > (maybe a couple other places).
>
> Maybe there's a way we can have libpqtypes adding calls into some
> hypothetical libpq hooks. So libpqtypes registers its hooks in _init()
> or some such, and it gets picked up automatically by any app that links
> to it.

I've been having some thoughts along those lines as well. As
currently written there is a already a de facto 'init' as the various
static type handlers are assembled into the type handlers for the
built in types.

About 50% of the patch as written is libpq plumbing which extends the
API, defines the structures, and various things like that. IMO, there
is very little point to abstracting that out into a separate library.
The 50% is the type handlers and various assorted conversion
functions. This half will only increase as we introduce new types and
other conversions. I think, if there is some reasonable case for
separation, it is here (the type handlers)...and I think this might
present a reasonable approach for dealing with version compatibility
issues. One thought I had was that a 8.4 libpq would be able to load
the 8.3 types when dealing with a 8.3 server for example. Maybe this
is a non-starter, but it's one case where splitting things out might
have some other advantages.

If this works the way I'm thinking about it, it would probably better
than a compile time flag...I don't think that satisfies anyway since
hardly anyone compiles their own libpq any more (presumably everyone
would just compile it in, making the check moot). Anyone with an
appreciation for irony and a long memory will recall me griping about
the odbc driver compiling openssl in, because it required me to
package in a bunch of extra dlls on windows :-).

In terms of moving the code to pgfoundry, I think this is absolutely
the wrong thing to do, except in terms of deciding the patch
unsuitable for inclusion into core (or deferring that decision).
People that used it would naturally expect changes to happen in
concert with the server. Better just to come to a consensus...in, or
out :-)

merlin