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
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 |