Re: [PATCHES] libpq type system 0.9a

Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> Kinda what my last suggestion was.  Some tid-bits need to be reside in libpq, 
>> but very little.  I was thinking PQtypesEnable(bool) which would dlopen 
>> libpqtypes and map all functions needed.  This would leave the function bodies 
>> of PQputf, PQgetf, PQparamExec, etc... as simple proxy functions to the 
>> dynamically loaded functions.  This removes any bloat that people don't like 
>> right now but still allows one to use libpq as the primary interface, rather 
>> than having to fiddle with libpq and some other API.
> 
> This is still 100% backwards.  My idea of a libpq hook is something that
> could be used by libpgtypes *and other things*.  What you are proposing
> is something where the entire API of the supposed add-on is hard-wired
> into libpq.  That's just bad design, especially when the adequacy of
> the proposed API is itself in question.
> 
> 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
> 

My idea was not a response to your hook idea.  It was different 
altogether.

My idea is trying to create one interface where some parts need to be 
enabled (nothing wrong with that design, this is a plugin-like model).

Your idea creates two interfaces where one of them can hook into the 
other.  These are two different concepts.

the question is, are you asking for two different interfaces or are you 
just looking to minimize overhead.  I thought it was the latter which is 
why I proposed a plugin-like model.  It removes bloat as well as 
maintains a single interface.  Nothing wrong with the design unless it 
doesn't meet your requirements.

Andrew