Dave Cramer-8 wrote:
>
> My understanding is this: Postgresql is an MVCC database and can
> easily provide you with a snapshot of a resultset inside a
> transaction. Outside a transaction my bet is that the data has to be
> copied to a temporary location somewhere, so if this is done over N
> connections the resources required could be substantial.
>
The solution is very simple. Just keep the version associated with the
current resultset around until the resultset is closed. This is basically
the same as having another connection, but in this case, each resultset on
the connection should use the version that was associated with the
connection when the resultset was opened.
> Well every database I know of has it's idiosyncrasies, an as I said
> the JDBC spec makes no guarantees of what setFetchSize should do if
> anything.
>
The JDBC spec also makes no guarantees that the database shouldn't crash.
The purpose of a spec isn't to limit what is provided to users, rather it is
to provide the minimum functionality that users can assume across
implementations.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/setFetchSize-tp4935215p4941054.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.