Re: For cursors, there is FETCH and MOVE, why no TELL?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marc Balmer <marc(at)msys(dot)ch>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: For cursors, there is FETCH and MOVE, why no TELL?
Date: 2015-02-10 15:21:53
Message-ID: 27269.1423581713@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marc Balmer <marc(at)msys(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-02-10 15:25:57 Re: For cursors, there is FETCH and MOVE, why no TELL?
Previous Message Tom Lane 2015-02-10 15:07:34 Re: Corner case for add_path_precheck