Re: proposal - plpgsql - FOR over unbound cursor

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - plpgsql - FOR over unbound cursor
Date: 2020-07-01 18:06:05
Message-ID: 690044.1593626765@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> Last week I played with dbms_sql extension and some patterns of usage
> cursor in PL/SQL and PL/pgSQL. I found fact, so iteration over cursor (FOR
> statement) doesn't support unbound cursors. I think so this limit is not
> necessary.

I guess I don't understand why we should add this. What does it do
that can't be done better with a plain FOR-over-SELECT?

The example you give of splitting an iteration into two loops doesn't
inspire me to think it's useful; it looks more like encouraging awful
programming practice.

> This statement can open portal for bound cursor or can iterate
> over before opened portal. When portal was opened inside FOR statement,
> then it is closed inside this statement.

And this definition seems quite inconsistent and error-prone.
The point of a FOR loop, IMO, is to have a fairly self-contained
definition of the set of iterations that will occur. This
eliminates that property, leaving you with something no cleaner
than a hand-built loop around a FETCH command.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2020-07-01 18:19:25 Re: SQL-standard function body
Previous Message Stephen Frost 2020-07-01 17:23:21 Re: Remove Deprecated Exclusive Backup Mode