Re: [HACKERS] Binary Cursors, and the COPY command - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: [HACKERS] Binary Cursors, and the COPY command
Date
Msg-id 4106D4D7.6070902@opencloud.com
Whole thread Raw
In response to Re: [HACKERS] Binary Cursors, and the COPY command  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc
Thomas Hallgren wrote:

> I'm the author of PL/Java. It uses its own JDBC driver on top of SPI.
> The main reason for thas is that I don't want the overhead of streaming
> data and flipping byte order when everything is readily available in
> memory. When "client" and "server" resides in the same process the
> overhead is measurable. By using java.nio in your JDBC, I beleive it
> would be possible to not just use native byte ordering, but perhaps also
> to create a nice abstraction allowing direct access to structures in
> memory rather than streaming data, thus obliviate the need for my own
> driver. And PL/Java will never run on Java 1.3 or older :-)
>
> Do you have any opinion on that?

This is a *lot* of work. There are bigger issues to deal with than the
use of NIO -- lots of the higher-level JDBC code makes assumptions about
the details of the protocol it is speaking. I've made some inroads on
that front with the V3 protocol rewrite I did recently but there will
still be a lot more work in that area.

That said, I can see that it might work with "SPI within the same
process" as a new underlying "protocol". That could use NIO or whatever
you want, and conditionally build that code only when 1.4 + the SPI
interface is available. The query/parameter abstraction that's currently
in place is intended to give the protocol flexibility about how it
represents the data (although it is pretty basic at the moment) so I
don't think it'd be necessary to have NIO in the protocol-independent
parts of the driver.

Anyway, good luck :)

-O

pgsql-jdbc by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: [HACKERS] Binary Cursors, and the COPY command
Next
From: "j.random.programmer"
Date:
Subject: Bug in 7.4_213 driver: returns VARCHAR instead of LONGVARCHAR for text types