Re: For cursors, there is FETCH and MOVE, why no TELL? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: For cursors, there is FETCH and MOVE, why no TELL?
Date
Msg-id 27269.1423581713@sss.pgh.pa.us
Whole thread Raw
In response to Re: For cursors, there is FETCH and MOVE, why no TELL?  (Marc Balmer <marc@msys.ch>)
Responses Re: For cursors, there is FETCH and MOVE, why no TELL?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

There are also backwards-compatibility reasons to be nervous about
changing the long-standing command tag values for these commands.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Corner case for add_path_precheck
Next
From: Pavel Stehule
Date:
Subject: Re: For cursors, there is FETCH and MOVE, why no TELL?