Re: BUG #14275: cursor's variable in pgsql doesn't respect scope

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(at)tao11(dot)riddles(dot)org(dot)uk>:
>>>>>>  "klimych" == klimych <klimych(at)tut(dot)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)