Just a reminder that we could use cursors that exist after transaction commit (WITH HOLD) and updatable cursors (WHERE CURRENT OF cursorname). :-)
--------------------------------------------------------------------------- Tom Lane wrote: > "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes: > >> There are cases where > >> identical cursor definitions might allow or not allow backwards fetch > >> depending on the planner's choices. > > > Would it be possible to give warnings in a narrow superset of the > > problematic cases, something along the lines of "I'm scrolling backwards > > for you now, but there's no reason why that should work on this same query > > tomorrow"? > > I don't see a practical way to do that --- that little bit of warning > code would have to embed a lot of fragile assumptions about the set of > alternatives searched by the planner. It would probably break every > time we improved the planner. And the breakage would consist either of > failing to give a warning when one is appropriate, or giving a warning > when no other plan is really likely to be chosen; neither of which are > going to be easily noticed or tested for. Seems like a losing game :-( > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
