| 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
| 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 |