Re: recursion in plpgsql

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: recursion in plpgsql
Дата
Msg-id 87muqlyltd.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: recursion in plpgsql  (David Gauthier <davegauthierpg@gmail.com>)
Ответы Re: recursion in plpgsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
>>>>> "David" == David Gauthier <davegauthierpg@gmail.com> writes:

 David> Tom: I seem to remember (but am probably wrong) that cursors
 David> were locally scoped (or could be made so). This was several
 David> years ago with an earlier v8 version. Was that sort of thing
 David> around back then ?

There are two distinct objects here being called "cursor": one is the
plpgsql variable, which is locally scoped, and the other is the actual
open portal, which must have a unique name within the session.

By default, plpgsql explicit bound cursors (but not plain "refcursor"
variables) take their portal name from the plpgsql variable name, and
hence don't work recursively by default. This is a convenience so that
code outside the function can use the same name to refer to the open
portal.

However, plpgsql cursor variables (whether declared bound or unbound)
can be assigned a text value or NULL _before_ being opened, and if so,
that value will be used for the portal name, or if NULL, a name of
"<unnamed portal N>" will be uniquely generated. (_After_ the open, the
variable's text value is the actually assigned portal name.) Unbound
refcursor variables default to NULL, so they are assigned unique portal
names on opening.

So in your example, adding

    child_node_curr := NULL;

immediately before the OPEN statement should be sufficient.

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Kellerer
Дата:
Сообщение: Re: why select count(*) consumes wal logs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: recursion in plpgsql