Re: scrollable cursor sup. for SPI

>Neil Conway <neilc(at)samurai(dot)com> writes:
> > BTW, how do people feel about the function names:
>
> > SPI_cursor_open_with_options
> > SPI_scroll_cursor_fetch
> > SPI_scroll_cursor_move
>
>I dislike the SPI_cursor_open_with_options API on the grounds that it
>lets people break things (CURSOR_OPT_HOLD for instance isn't likely
>to do anything good) and it doesn't actually provide any functionality
>that wasn't there before (the existing code already sets OPT_SCROLL
>if possible). I'd suggest losing that one entirely and just adding
>the FetchDirection-as-substitute-for-"forward" entry points.
>

First variant of this "open" function controlls only sroll option. But there
are other option which we have to controll in futere like INSENSITIVE,
SENSITIVE, FOR UPDATE and it's reason for _with_options.

if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is cheap
(not when is possible). It's true?

/*
* Set up options for portal.
*
* If the user didn't specify a SCROLL type, allow or disallow
scrolling
* based on whether it would require any additional runtime overhead
to do
* so.
*/
portal->cursorOptions = stmt->options;
if (!(portal->cursorOptions & (CURSOR_OPT_SCROLL |
CURSOR_OPT_NO_SCROLL)))
{
if (ExecSupportsBackwardScan(plan))
portal->cursorOptions |= CURSOR_OPT_SCROLL;
else
portal->cursorOptions |= CURSOR_OPT_NO_SCROLL;

_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/