From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | 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-15 21:21:02 |
Message-ID: | 4148B23E.7020009@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
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).
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-09-15 21:56:28 | Re: 'TID index' |
Previous Message | Gaetano Mendola | 2004-09-15 21:04:11 | Re: x86_64 configure problem |