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]

Reply via email to