Re: AW: selecting from cursor
От | Tom Lane |
---|---|
Тема | Re: AW: selecting from cursor |
Дата | |
Msg-id | 18210.994169573@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | AW: selecting from cursor (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> 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
В списке pgsql-hackers по дате отправления: