Re: Error message with plpgsql CONTINUE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Error message with plpgsql CONTINUE
Date
Msg-id 21320.1440202918@sss.pgh.pa.us
Whole thread Raw
In response to Re: Error message with plpgsql CONTINUE  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Error message with plpgsql CONTINUE  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Error message with plpgsql CONTINUE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 8/17/15 9:48 AM, Tom Lane wrote:
>>> I'm inclined to think that if we wanted to make this better, the way to
>>> improve it would be to detect the error*at compile time*, and get rid of
>>> this hack in plpgsql_exec_function altogether.

> Here's a patch that does that. This also made it possible to check for 
> CONTINUE/EXIT being used outside a loop during parsing, so I changed 
> that as well and removed those checks from pl_exec.c.

Applied with some fixes.  The major oversight was that EXIT does *not*
have the same rules as CONTINUE, as is clearly documented (though in your
defense, there was no regression test verifying the behavior ... there is
now).

> I refactored the 3 
> places that were doing the check into exec_stmt_block(), renaming the 
> original function exec_stmt_block_rc for the one place that still needs 
> the return code.

I did not like that part.  Simpler and less code churn to just take out
the now-unnecessary outer-level tests.  Also, your way lost the separate
error texts for "control reached end of function" and "control reached end
of trigger procedure", which while maybe not very important was not an
agreed-to change.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Qingqing Zhou
Date:
Subject: Re: CTE optimization fence on the todo list?
Next
From: Greg Stark
Date:
Subject: Re: PostgreSQL for VAX on NetBSD/OpenBSD