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 you
can do it.
Regards
Pavel
>
> 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)
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
