"Pavel Stehule" <[EMAIL PROTECTED]> 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/


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to