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 [EMAIL PROTECTED]) > -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com ---------------------------(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
