On Thursday 06 March 2003 19:08, Bruce Momjian wrote:
> Jeroen T. Vermeulen wrote:
> > On Tue, Feb 25, 2003 at 02:04:50PM +0100, Christoph Haller wrote:
> > > Anyway, you may MOVE until 0 instead of FETCH, or use the COUNT()
> > > function on the query to learn about the number of rows to be returned.
> >
> > Hmm... Wouldn't the reliability of a count() depend on the isolation
> > level?
> >
> > OTOH the problem with MOVE ALL is that not all cursors support backward
> > scrolling, apparently, and there is no clear documentation (or even
> > diagnostics!) to determine whether they do.
>
> 7.4 does document MOVE ALL as going to the end of the cursor.
Great, Bruce is back !
I drop the idea to use cursors for recordset buffering, and I'm using temp
tables. MOVE ALL can solve my first problem, but It can't solve the other
one: How to know if there is transaction in progress ? The final facts were:
For cursor:
Fast, and less memory (concerning that only query plan is stored on
server).
Against cursor:
I can't determine if transaction is already in progress, so I do not
know can I COMMIT on cursor close. (Maybe some other of my recordset
controls started transactions before)
For table:
I do not need transaction
Against table:
More memory, and slower positioning in the buffer(using LIMIT and
OFFSET)
OK it is slower, but it works !
I must say one more thing I noticed experimenting with cursors:
Let's say that we have cursor with 10 rows, if we MOVE 11 rows, cursor
become unusable, because even if we after that MOVE -5, no row can be
fetched. I do not think that this is bug, but at last notice should be raised
with warning that we missed the cursors size. I even find the code that is
working with cursor, and tried to figure out how to fix this, but it is too
much for me. Sorry !
Regards !
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
