Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, how do people feel about the function names:
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
* based on whether it would require any additional runtime overhead
portal->cursorOptions = stmt->options;
if (!(portal->cursorOptions & (CURSOR_OPT_SCROLL |
portal->cursorOptions |= CURSOR_OPT_SCROLL;
portal->cursorOptions |= CURSOR_OPT_NO_SCROLL;
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend