Обсуждение: Does 8.3/8.4 support lazy fetched + updateable +scrollable ResultSets?
Hello, First of all thank you for postgres. Its an amazing piece of software. I've a legacy software which relies on updateable+scrollable ResultSets running on postgres 7.4. Unfourtunatly this version didn't support lazy updateable ResultSets, so when the ResultSet is opened the whole query contents are sent to the client at once instead of lazily - which starts to become a serious performance problem the more data is inserted. Does Pg 8.3 or 8.4 support lazy fetched + updateable +scrollable ResultSets? Thank you in advance, Clemens
On Sun, 17 May 2009, Clemens Eisserer wrote: > Does Pg 8.3 or 8.4 support lazy fetched + updateable +scrollable > ResultSets? > No. Kris Jurka
Re: Does 8.3/8.4 support lazy fetched + updateable +scrollable ResultSets?
От
Clemens Eisserer
Дата:
Thanks for the clarification. Is it just the jdbc-driver lacking that functionality, or is backend functionality missing too? Thanks, Clemens 2009/5/18 Kris Jurka <books@ejurka.com>: > > > On Sun, 17 May 2009, Clemens Eisserer wrote: > >> Does Pg 8.3 or 8.4 support lazy fetched + updateable +scrollable >> ResultSets? >> > > No. > > Kris Jurka >
On Mon, 18 May 2009, Clemens Eisserer wrote: > Is it just the jdbc-driver lacking that functionality, or is backend > functionality missing too? > You can look at it both ways. Around the 7.4 release we had a patch that almost worked for scrollable, cursor based resultsets, but it had some bugs and never got committed. At the time the driver converted queries to explicit DECLARE CURSOR statements and then the patch made it do MOVE and FETCH commands to retrieve the desired data. For the 8.0 release the driver was rewritten to use protocol level commands to create "portals" which are more or less equivalent to cursors. Unfortunately portals can only move forward so they aren't scrollable. The JDBC team's position is that the backend and protocol lack support for scrollable portals and that's what we're waiting for to implement this feature. Kris Jurka