Re: libpq and prepared statements progress for 8.0

David Wheeler <david(at)kineticode(dot)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.

The second problem is the one someone already pointed out, that you
*need* multiple implementations in order to keep the protocol definition
honest.

I don't necessarily disagree about the immediate issues. I think it
would be a win to reimplement the ODBC driver atop libpq (if it's a
comfortable fit --- but not if we have to add warts to libpq to make
it work). And I don't feel any strong need to redo DBD::Pg as a
native-Perl driver. But I disagree that either of those decisions
should be taken on the basis of an "everyone should use libpq"
philosophy. Rather they should be taken on the basis of what makes
sense for each of those projects individually.

regards, tom lane