Re: PL/pgSQL cursors should get generated portal names by default

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, wolakk(at)gmail(dot)com, Jan Wieck <jan(at)wi3ck(dot)info>
Subject: Re: PL/pgSQL cursors should get generated portal names by default
Date: 2022-11-04 07:22:44
Message-ID: CAFj8pRACrRJ7kd29jtzy=kXxHn73P9S7wDoC3LVYqfjKahki3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

st 2. 11. 2022 v 0:39 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> There's a complaint at [1] about how you can't re-use the same
> cursor variable name within a routine called from another routine
> that's already using that name. The complaint is itself a bit
> under-documented, but I believe it is referring to this ancient
> bit of behavior:
>
> 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.
>
> So if you try to nest usage of two bound cursor variables of the
> same name, it blows up on the portal-name conflict. But it'll work
> fine if you use unbound cursors (i.e., plain "refcursor" variables):
>
> But an unbound cursor
> variable defaults to the null value initially, so it will receive
> an automatically-generated unique name, unless overridden.
>
> I wonder why we did it like that; maybe it's to be bug-compatible with
> some Oracle PL/SQL behavior or other? Anyway, this seems non-orthogonal
> and contrary to all principles of structured programming. We don't even
> offer an example of the sort of usage that would benefit from it, ie
> that calling code could "just know" what the portal name is.
>
> I propose that we should drop this auto initialization and let all
> refcursor variables start out null, so that they'll get unique
> portal names unless you take explicit steps to do something else.
> As attached.
>
> (Obviously this would be a HEAD-only fix, but maybe there's scope for
> improving the back-branch docs along lines similar to these changes.)
>
>
I am sending an review of this patch

1. The patching, compilation without any problems
2. All tests passed
3. The implemented change is documented well
4. Although this is potencial compatibility break, we want this feature. It
allows to use cursors variables in recursive calls by default, it allows
shadowing of cursor variables
5. This patch is short and almost trivial, just remove code.

I'll mark this patch as ready for commit

Regards

Pavel

> regards, tom lane
>
> [1]
> https://www.postgresql.org/message-id/166689990972.627.16269382598283029015%40wrigleys.postgresql.org
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2022-11-04 07:28:50 Re: Privileges on PUBLICATION
Previous Message Masahiko Sawada 2022-11-04 05:43:10 Re: Fix comments atop ReorderBufferAddInvalidations