Re: streaming result sets: progress

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

In response to

Browse pgsql-jdbc by date

  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