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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: For cursors, there is FETCH and MOVE, why no TELL?
Дата
Msg-id 27269.1423581713@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: For cursors, there is FETCH and MOVE, why no TELL?  (Marc Balmer <marc@msys.ch>)
Ответы Re: For cursors, there is FETCH and MOVE, why no TELL?
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Corner case for add_path_precheck
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: For cursors, there is FETCH and MOVE, why no TELL?