Re: proposal - plpgsql - FOR over unbound cursor - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal - plpgsql - FOR over unbound cursor
Date
Msg-id 690044.1593626765@sss.pgh.pa.us
Whole thread Raw
In response to proposal - plpgsql - FOR over unbound cursor  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal - plpgsql - FOR over unbound cursor  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Remove Deprecated Exclusive Backup Mode
Next
From: Vik Fearing
Date:
Subject: Re: SQL-standard function body