Well, the proposal of implementing it like holdable cursors means using
a Materialize node which, if I understand correctly, means taking the
whole result set and storing it on memory (or disk).
Would it help to hold the lock for a record that is the current cursor position,
iff this record
Jeroen T. Vermeulen wrote:
That makes me wonder why people want to maintain transactionality w.r.t.
nested transactions but not with outer ones. Odd!
Yep.
But then the FETCH should still occur before the transaction as far as I'm
concerned. You fetch a batch (if it fails, you terminate) and
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
This is a non-starter for JDBC: it has no control over when an
application decides to access a ResultSet in a way that results in a
FETCH of new data.
From what you're telling me, I'm not sure I like JDBC! Why did they come
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
Buffering *all* the ResultSet data client-side isn't an option --
cursors are used specifically to handle resultsets that don't fit into
heap on the client side. And implementing a disk cache or similar a)
doesn't work if you
Alvaro Herrera wrote:
Well, the proposal of implementing it like holdable cursors means using
a Materialize node which, if I understand correctly, means taking the
whole result set and storing it on memory (or disk). So the same
question arises: why bother implementing that at all? Of course the
