Re: For cursors, there is FETCH and MOVE, why no TELL?
От | Pavel Stehule |
---|---|
Тема | Re: For cursors, there is FETCH and MOVE, why no TELL? |
Дата | |
Msg-id | CAFj8pRBZC+bgETnm7QjPDdQinbmcnmBwp+Wq2K389dx3RCiWzg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: For cursors, there is FETCH and MOVE, why no TELL? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2015-02-10 16:21 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
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
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: