Re: libpq and prepared statements progress for 8.0 - Mailing list pgsql-hackers

From Greg Stark
Subject Re: libpq and prepared statements progress for 8.0
Date
Msg-id 87656ere5x.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: libpq and prepared statements progress for 8.0  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: libpq and prepared statements progress for 8.0  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-hackers
Oliver Jowett <oliver@opencloud.com> writes:

> > Well benefits that boil down to "Java sucks" aren't very convincing. Perl
> > suffers from no such handicap.
> 
> Arguing that Java-specific benefits are not convincing benefits for a JDBC
> driver because you don't get them in Perl seems a bit odd to me. You're not
> implementing the driver in Perl!

Er, we're kind of on two different wavelengths here. What I'm trying to
determine are what are the benefits of writing a pure-perl driver versus one
that implements the protocol in a C module, versus one that merely interfaces
with libpq.

The current Perl module interfaces with libpq. The closest analogue to use for
comparison is the JDBC driver which is a pure-Java implementation. So the
benefits and disadvantages the JDBC driver faces are useful data points.
However benefits that arise purely because of quirks of Java and don't relate
to Perl are less relevant than benefits and disadvantages that are more
general.

I wasn't trying to criticize the decisions behind the JDBC implementation. It
may well be that the choice that makes sense for Java isn't the same as the
choice that makes sense in other languages. Or it may be that there are
lessons that can be learned from Java that generalize to other languages and
a pure perl implementation may make sense.

-- 
greg



pgsql-hackers by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: libpq and prepared statements progress for 8.0
Next
From: Greg Stark
Date:
Subject: Re: PL/PgSQL "bare" function calls