Re: [HACKERS] Binary Cursors, and the COPY command
От | Oliver Jowett |
---|---|
Тема | Re: [HACKERS] Binary Cursors, and the COPY command |
Дата | |
Msg-id | 4106D4D7.6070902@opencloud.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Binary Cursors, and the COPY command (Oliver Jowett <oliver@opencloud.com>) |
Список | 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 по дате отправления: