From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: libpq and prepared statements progress for 8.0 |
Date: | 2004-09-16 04:20:36 |
Message-ID: | 87mzzqrgiz.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> Greg Stark wrote:
>
> > I was pretty shocked when I heard that JDBC implements the low level protocol
> > itself. It seems like a dead-end strategy to me. Any new protocol innovations
> > need to be implemented in every driver. Every implementation gets the chance
> > to reimplement the same bugs and same inefficiencies over and over again.
>
> There *are* benefits to implementing the protocol directly. First on my
> personal list is that our Java application would not be able to use postgresql
> at all if the driver required JNI/libpq.
Well benefits that boil down to "Java sucks" aren't very convincing. Perl
suffers from no such handicap. There are tons of Perl modules that have C
implementations. Sometimes simply for speed or convenience. Perl makes it
pretty convenient to write modules in C or interface with C libraries without
too much pain.
Hell, it's not the recommended way to make modules but for convenience you
can't really beat:
perl -e 'use Inline C=>q{void greet() {printf("Hello, world\n");}}; greet'
The only benefit for a pure-perl driver would be the ease of use for Windows
users. And that only really matters because Windows users tend to be more
averse to using a compiler and often don't even have one installed.
> There are also some things in the JDBC API that seem hard to map to the current
> libpq API, e.g. streaming parameter data from a Java stream without taking an
> intermediate copy.
Ah, this is another problem. It boils down to "libpq sucks" at least for the
needs of a driver writer. I'm becoming convinced that libpq's problem was that
it's trying to satisfy two users, C programmers using postgres directly and
driver authors who just want a low level interface to the protocol.
What I'm trying to decide is whether the best course of action is to write a
different implementation for a perl driver (either in Perl or in C) or to fix
libpq to be more useful for driver authors.
> The protocol implementation is not really all that complex. The implementation
> for both V2 and V3 weighs in at ~6k lines of Java out of ~38k total, and much
> of that is connection-state juggling that we'd have to do anyway if using libpq
> (working out when to send BEGIN, breaking up multiple-statement queries into
> individual statements and matching the results up, managing portal state, etc).
I'll have to look at these things more closely. I wonder whether it makes
sense for JDBC, ODBC, DBD::Pg to all have independent implementations of these
features.
Incidentally, does the JDBC spec really allow for multiple-statement queries
at all?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2004-09-16 04:45:55 | Re: libpq and prepared statements progress for 8.0 |
Previous Message | Neil Conway | 2004-09-16 03:40:44 | Re: PL/PgSQL "bare" function calls |