>"Pavel Stehule" <pavel.stehule@hotmail.com> writes:
> > if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is
>cheap
> > (not when is possible). It's true?
>
>Nope. If you want a scrollable plan you need to make sure you tell the
>planner about it. SPI_cursor_open is not in charge, it's merely looking
>at what the planner did.
>
>As for that other stuff, when and if we support it, it would be time to
>add a SPI entry point that supports it. I'm disinclined to add an API
>on speculation though --- by the time the feature actually exists, we
>might not like the API anymore anyway.
>
I did step back and did some test. game with CURSOR_OPT_SCROLL has not sense
in SPI_cursor_open. I didn't tests with table's joins where this problem is
visible before.
I propose add new function SPI_prepare_with_option(..) which allow set
option for planner. Isn't problem add to SPI_open_cursor assert for holdable
cursors. This needs propably rewriting functions pg_plan_query and
pg_plan_queries.
Or new function SPI_prepare_cursor(...) which can be similar
PerformCursorOpen. This doesn't change others functions.
All comments are welcome
Pavel Stehule
_________________________________________________________________
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
