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" <jtv@xs4all.nl> 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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073