Re: recursion in plpgsql

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: David Gauthier <davegauthierpg(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, scrawford(at)pinpointresearch(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: recursion in plpgsql
Date: 2018-11-07 15:17:33
Message-ID: 87muqlyltd.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>>>>> "David" == David Gauthier <davegauthierpg(at)gmail(dot)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)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2018-11-07 15:27:53 Re: recursion in plpgsql
Previous Message Thomas Kellerer 2018-11-07 14:43:05 Re: why select count(*) consumes wal logs