Marc Balmer <marc@msys.ch> writes: > That is simple indeed. I tend to think, however, that it would be > cleaner to return the position as a proper result from a functionn > instead of using a "side effect" from a FETCH/MOVE command.
Yeah. For one thing, a command tag wouldn't help you at all if you wanted to know the current cursor position inside a plpgsql function.
It can solved via GET DIAGNOSTICS statement
There are also backwards-compatibility reasons to be nervous about changing the long-standing command tag values for these commands.
yes, this is serious risk - and this is too high cost for relative less used feature.
Regards
Pavel
An issue that would have to be addressed is what the function ought to do if posOverflow is set, which is entirely feasible on Windows (or anyplace else where "long" is only 32 bits). Maybe we should redeclare portalPos as int64 and get rid of the posOverflow logic.
