> resultSetSize() does a number of FETCH ABSOLUTEs, throwing away the
> results, and then backtracking when it reaches a row that doesn't
> exist. A better strategy might be to use MOVE FORWARD ALL and examine
> the rowcount in the returned command tag.
Nice. I didn't know about MOVE. I have re-coded the size method to use
this pattern. Much better. I wish I had know about that before, I only
use SQL92 standard in my code but this is perfect for here. Thanks!
> fetchAbsolute() and things that end up calling it doesn't seem to
> respect the fetchsize, i.e. you always end up with a single-row
> resultset in memory. How about executing "MOVE ABSOLUTE n; FETCH
> FORWARD fetchsize" instead of just "FETCH ABSOLUTE n"?
Now that I have code in place for MOVE, this will be simple to
> How does the performance of iterating backwards through a resultset
> compare with the non-cursor case or the forward iteration case? It
> seems like with the patch it will end up doing a FETCH ABSOLUTE of a
> single row on each iteration. Really fetchAbsolute needs to do either
> a "MOVE ABSOLUTE n; FETCH FORWARD fetchsize" or "MOVE ABSOLUTE n;
> FETCH BACKWARD fetchsize" depending on the resultset's preferred fetch
> direction (see setFetchDirection)
Okay, now I must ask for some help. In the case that the direction is
reverse, does that mean that the pointer should position itself at the
last record at the beginning? What about unknown, should that default
Also, when in reverse mode should next() still go forward, or should
everything be reversed? Meaning, next() would go backwards and
previous() would go forwards?
> I have a number of code style comments too, let me know if you'd like
> the gory details :)
I usually stick to the Sun standards with 4 spaces for tabs. I noticed
that in this code there were a lot of different styles being used,
probably from different people making changes. I assumed that a
convention was not official. If there is a certain style that you would
like me to use let me know, if you like I can let IDEA just reformat
everything based on Sun standards, but that would be a big patch.
In response to
pgsql-jdbc by date
|Next:||From: Brian Olson||Date: 2004-05-01 01:49:03|
|Subject: Re: v3 from the ground up|
|Previous:||From: Oliver Jowett||Date: 2004-04-30 23:01:53|
|Subject: Re: Result Set Cursor Patch|