Because the driver would have to dedicate a connection to the backend to the resultset 
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 
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 [EMAIL PROTECTED])

Joseph Shraibman
Increase signal to noise ratio.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to