Re: BUG #14275: cursor's variable in pgsql doesn't respect scope
От | klimych@tut.by |
---|---|
Тема | Re: BUG #14275: cursor's variable in pgsql doesn't respect scope |
Дата | |
Msg-id | 634371470315822@web8h.yandex.ru обсуждение исходный текст |
Ответ на | Re: BUG #14275: cursor's variable in pgsql doesn't respect scope (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #14275: cursor's variable in pgsql doesn't respect scope
|
Список | pgsql-bugs |
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) 03.08.2016, 16:03, "Andrew Gierth" <andrew@tao11.riddles.org.uk>: >>>>>> Â "klimych" == klimych <klimych@tut.by> writes: > > Â klimych> Executing of the code gives error "cursor "cur" already in > Â klimych> use". > > The cursor name (portal name) is global to the session, and for a bound > cursor it defaults to the name of the cursor variable: > > 40.7.3.5. Returning Cursors > > Â Â [...] > > Â Â Note: A bound cursor variable is initialized to the string value > Â Â representing its name, so that the portal name is the same as the > Â Â cursor variable name, unless the programmer overrides it by assignment > Â Â before opening the cursor. But an unbound cursor variable defaults to > Â Â the null value initially, so it will receive an > Â Â automatically-generated unique name, unless overridden. > > It's a bit ugly, but you can do > > declare > Â Â cur for select 1; > begin > Â Â cur := null; -- force a unique generated portal name > Â Â open cur; > Â Â //... > > -- > Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: