In article <12594.1095699940@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> writes:
> David Wheeler <david@kineticode.com> writes:
>> On Sep 20, 2004, at 12:34 AM, Bruce Momjian wrote:
>>> I think we should favor libpq usage wherever possible and only
>>> re-implement it in the native language when required, like for
>>> jdbc/java.
>> I don't normally post "me too" posts, but I think that what Bruce says
>> here is extremely important.
> Allow me to state a contrary position ;-)
> The first problem with this approach is that it requires libpq to be all
> things to all people. We've already had some discussion in this thread
> about the tension between supporting application programs written in C,
> which want one set of features, and drivers, which need some other ones.
> After awhile you end up with a bloated, probably buggy library. We're
> already some way down that path, and I don't care to go much further.
I don't think that's what David meant, although he said so :-)
What we should have is a C API especially for use by driver authors;
probably this API is so far away from the rest of libpq that it should
not be part of it.
This API could make life easier for driver authours, resulting in more
and better drivers for more languages.
> The second problem is the one someone already pointed out, that you
> *need* multiple implementations in order to keep the protocol definition
> honest.
Nobody forces a driver author to use that API, and there are driver
authors who *cannot* use it, e.g. Java. This means there will be more
than one implementation anyways.