Re: [PATCHES] libpq type system 0.9a - Mailing list pgsql-hackers

Tom Lane wrote:
> 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.

Agreed.  A minimal change to libpq has a much better chance of being
accepted.  Let me remind people that the community is not required to
accept any patch --- it is accepted based on community feedback.  If we
accepted everything our API would be a mess and Postgres would be much
harder to use.

I think a wise thing would be for the patch submitters to give a _basic_
outline of what PQparam is trying to accomplish --- I mean like 10-20
lines with a code snippet, or code snippet with/withouth PQparam.  Right
now there are too many people trying to guess.  Of course, this should
have been done at the start.  I found this posting from August, 2007 but
it isn't short/clear enough:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00630.php

I feel this API is foreign enough from what people expect from a typical
database interface library that it should be a separate library with its
own documentation, whether the library is a separate directory in core
or in pgfoundry.

FYI, it might be interesting to extend it to cover what ecpg wants ---
we have been looking for a way to get the database-dependent parts of
ecpg out of the ecpg directory and this might be a solution, _even_ if
it makes your library larger.

Again, I don't think we have trouble with another library, assuming it
does something that many people want to do and it is so tied to the
backend that it needs to be in core. (However, Tom's mention that the
OIDs don't change weakens the logic that is should be in core.)

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +