Re: recursion in plpgsql - Mailing list pgsql-general

From Andrew Gierth
Subject Re: recursion in plpgsql
Date
Msg-id 87muqlyltd.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: recursion in plpgsql  (David Gauthier <davegauthierpg@gmail.com>)
Responses Re: recursion in plpgsql
List 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 by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: why select count(*) consumes wal logs
Next
From: Tom Lane
Date:
Subject: Re: recursion in plpgsql