Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
this. Given that cursors (are supposed to) support FETCH BACKWARDS,
I really don't see why they shouldn't be expected to handle ReScan...
I thought only scrollable cursors can do that. What if cursor isn't
scrollable? Should it error during the execution?
In PostgreSQL, all cursors are scrollable. The allowed grammar keyword is
simply ignored. I am actually not sure that this is optimal, since there
are a few very effective optimizations, that you can do if you know, that
ReScan is not needed (like e.g. not storing the result temporarily).
It's worse than that: we don't distinguish plans for cursors from plans
for any other query, hence *all* query plans are supposed to be able to
run backwards. (In practice, a lot of them don't work :-(.) Someday
that needs to be improved. It would be good if the system understood
whether a particular plan node would ever be asked to rescan itself or
run backwards, and could optimize things on that basis.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
