Because the driver would have to dedicate a connection to the backend to the resultset to
make sure nobody else tries to begin/end a block while it is trying to use a cursor.
(that's the simple explanation) Since a connection to the backend currently requires a
fork, it would be a real resource hog.
Kovács Péter wrote:
> Hi,
>
> I have a question for which I can think of an answer, but still I am
> uncertain about it.
>
> Why the scrollable result sets are not implemented in the current jdbc
> driver? Is it technically impossible or just no one needed this feature yet?
>
> The answer is probably that due to the lack of backend support for updatable
> cursors the scrollable result set would not be fully functional. (On the
> face of it, I think that it should be possible to build support for
> read-only scrollable result set into the jdbc driver.) But would a halfway
> solution not be better than nothing? You need to resort to workarounds
> anyway, if you want to use cursor based data processing with PostgreSQL.
> IMHO, a read-only scrollable result set would definitly be an important step
> toward code portability.
>
> Any comments?
>
> Does anyone have info on whether there are plans to implement support for
> updatable cursors in the backend? If there are, what are they?
>
> Thank you
>
> Peter
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com
