From: | nferrier(at)tapsellferrier(dot)co(dot)uk |
---|---|
To: | Scott Lamb <slamb(at)slamb(dot)org> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: streaming result sets: progress |
Date: | 2002-11-15 13:22:32 |
Message-ID: | uheej2civ.fsf@tapsellferrier.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Scott Lamb <slamb(at)slamb(dot)org> writes:
> First, my understanding is that cursors are only valid within the
> transaction in which they were created. Is this correct?
>
> If so, I can't use the cursor method exclusively. Some of my code needs
> to be able to iterate over a resultset and execute whole transactions
> based on it. With cursors, it would fail after the first iteration of
> the loop.
>
> From the archives, Barry Lind's plan at one point was to not use
> cursors unless setFetchSize() was used explicitly. [*] That would keep
> existing code working. Or otherwise, they should not be used if I
> specify ResultSet.HOLD_CURSORS_OVER_COMMIT; I could add that to my code
> where it is important. If/when the backend changes to support holding
> cursors over commit, then they could be used in all cases.
>
> Does this sound reasonable?
I've been thinking about it this morning... I think that we're going
to have to drop the idea of keeping the cursor open and go with the
idea suggested earlier (sorry, I forget by who) of issuing multiple
SQL statements slightly hacked to limit the row set.
Otherwise it's just not going to fly with multiple statements.
Nic
From | Date | Subject | |
---|---|---|---|
Next Message | snpe | 2002-11-15 14:03:37 | Re: streaming result sets: progress |
Previous Message | Scott Lamb | 2002-11-15 13:00:26 | Re: streaming result sets: progress |