Re: BUG #14275: cursor's variable in pgsql doesn't respect scope
От | David G. Johnston |
---|---|
Тема | Re: BUG #14275: cursor's variable in pgsql doesn't respect scope |
Дата | |
Msg-id | CAKFQuwbMNt4yyKYRPEAVy5CdkYZ0Qf52fsQsTfiiDPwDxrOd-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14275: cursor's variable in pgsql doesn't respect scope (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-bugs |
On Thu, Aug 4, 2016 at 10:10 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > 2016-08-04 15:03 GMT+02:00 klimych@tut.by <klimych@tut.by>: > >> Thank you! >> Sorry, I should read the documentation more carefully (athough I didnt't >> expect to find explanation of such behaviour in "Returning Cursors" >> section, as well as I didn't belive such behaviour could be made on >> purpose). >> And thanks again for workaround! It seems to be the only way to use >> cursors in pl/pgsql (the weirdest thing I've ever seen, I should say) >> > > I agree so this is little bit strange - it looks like workaround of some > historical limit of SPI. It is too late to change. But it has some > advantage. Postgres can't to pass parameters by ref. With named cursors y= ou > can do it. > > =E2=80=8BThe docs could maybe be improved, though it is documented and bein= g mis-informed simply results in an error and a question on the lists, so expending get mental effort here isn't that appealing. Improving the code would involve something like: OPEN unbound_cursorvar [ [ NO ] SCROLL ] [ NAME system_name ] FOR query Also, would a hint on the error message be too much to ask? HINT: by default the global name of the cursor is equal to the variable name to which it is assigned David J. =E2=80=8B
В списке pgsql-bugs по дате отправления: