Re: recursion in plpgsql

From: David Gauthier <davegauthierpg(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, scrawford(at)pinpointresearch(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: recursion in plpgsql
Date: 2018-11-07 14:35:30
Message-ID: CAMBRECD2w_+2rm87bYTLWQqyhmmOo2w7gVBU5Rk8R-_T4+ryrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks for the replies !

Steve: I don't remember using a recursive query like that, but it certainly
does look interesting.

Tom: I seem to remember (but am probably wrong) that cursors were locally
scoped (or could be made so). This was several years ago with an earlier
v8 version. Was that sort of thing around back then ?
Perhaps I stuffed the results in an array or temp table and then fed out of
that in recursive calls. I remember having to stuff arrays in oracle 8 WAY
back in the day, and then read out of that for recursive calls. But I also
seem to remember being delighted with plpsql because that wasn't necessary
anymore.

On Tue, Nov 6, 2018 at 7:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Gauthier <davegauthierpg(at)gmail(dot)com> writes:
> > I'm trying/failing to write a recursive plpgsql function where the
> function
> > tries to operate on a hierary of records in a reflexive table.
> > parent-child-grandchild type of recursion.
> > I tried with a cursor, but got a "cursor already in use" error. So that
> > looks like scoping.
>
> IIRC, the "portal" underlying a plpgsql cursor just gets the same name
> as the cursor variable by default, so you'll get portal-name conflicts
> with the coding style you show here.
>
> It's possible to avoid that by ensuring that each cursor gets a different
> portal name. I'm too lazy to check the details right now, but at the
> very least there's a way to do it by declaring the variable as "refcursor"
> and assigning it a different name at each nesting depth. There might be
> some more elegant solution, too.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2018-11-07 14:43:05 Re: why select count(*) consumes wal logs
Previous Message Ravi Krishna 2018-11-07 14:10:22 Re: why select count(*) consumes wal logs