On 27 October 2011 09:22, fschmidt <fschmidt@gmail.com> wrote:
>
> 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.
All this has already been solved, since WITH HOLD is supported for
cursors. (I think the actual implementation there copies out to
temporary storage, so perhaps the MVCC approach you suggest is not so
straightforward). Anyway, the missing part is a similar sort of
support for portals at the protocol level - I suggest you aim your
efforts at getting that supported on the server side, since the driver
can't do anything until that is supported.
>> 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.
I think Dave's point here is that the docs for setFetchSize()
explicitly says that it's a hint to the driver and the driver is free
to ignore it, so a portable application shouldn't be relying on
particular behavior.
Oliver
