pg.ddx.io pgsql-sql@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Porting from db2 problem 2+ messages / 2 participants [nested] [flat]
* Porting from db2 problem @ 2003-02-23 11:11 Wayne Armstrong <wdarmst@bacchus.com.au> 0 siblings, 0 replies; 2+ messages in thread From: Wayne Armstrong @ 2003-02-23 11:11 UTC (permalink / raw) To: pgsql-sql Hi, I am trying to port an app that currently runs over db2 and oracle (on windows os/2 linux hpux aix etc) to also run over postgres. I am currently porting the windows client (using odbc). I am having major problems because of the lack of with hold cursors (cursors that remain open over a commit) in postgres. There are a lot of places where the app will - open a cursor with hold - fetch the first 20 or so rows, allow the user to scroll thru the result set, updating and commiting changes to particular rows as they go. When the user gets to the end of the current set of fetched rows - the app will fetch the next 20 or so during a scroll down operation etc. The user may hold the read-only cursor over the result-set all day, and it is important that rows that they do update, be immediately available for other users. What do folk do to support this kind of scenario in the abscence of with hold cursors ? Is implementation of with hold cursors likely in the near future? Regards, Wayne ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Porting from db2 problem @ 2003-02-24 09:30 Christoph Haller <ch@rodos.fzk.de> 0 siblings, 0 replies; 2+ messages in thread From: Christoph Haller @ 2003-02-24 09:30 UTC (permalink / raw) To: pgsql-sql; +Cc: wdarmst@bacchus.com.au > > I am trying to port an app that currently runs over db2 and oracle (on windows > os/2 linux hpux aix etc) to also run over postgres. > I am currently porting the windows client (using odbc). > I am having major problems because of the lack of with hold cursors (cursors > that remain open over a commit) in postgres. There are a lot of places where > the app will - open a cursor with hold - fetch the first 20 or so rows, allow > the user to scroll thru the result set, updating and commiting changes to > particular rows as they go. When the user gets to the end of the current set of > fetched rows - the app will fetch the next 20 or so during a scroll down > operation etc. The user may hold the read-only cursor over the result-set all > day, and it is important that rows that they do update, be immediately > available for other users. > > What do folk do to support this kind of scenario in the abscence of with hold > cursors ? Have a look at SELECT ... FOR UPDATE ... LIMIT ... OFFSET ... ; > Is implementation of with hold cursors likely in the near future? > I have no idea. Sorry. Regards, Christoph ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2003-02-24 09:30 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2003-02-23 11:11 Porting from db2 problem Wayne Armstrong <wdarmst@bacchus.com.au> 2003-02-24 09:30 Re: Porting from db2 problem Christoph Haller <ch@rodos.fzk.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox