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

From Tom Lane
Subject Re: Error message with plpgsql CONTINUE
Date
Msg-id 1454.1439847995@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  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Error message with plpgsql CONTINUE  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
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.

> So split PLPGSQL_NSTYPE_LABEL into PLPGSQL_NSTYPE_BLOCK_LABEL and 
> PLPGSQL_NSTYPE_LOOP_LABEL, and split opt_block_label and opt_label the 
> same way?

I think using two NSTYPE codes would probably be a pain because there are
numerous places that don't care about the distinction; it'd be better to
have a secondary attribute distinguishing these cases.  (It looks like you
could perhaps reuse the "itemno" field for the purpose, since that seems
to be going unused in LABEL items.)

You likely do need to split opt_block_label into two productions, since
that will be the easiest way to pass forward the knowledge of whether
it's being called from a loop or non-loop construct.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: More WITH
Next
From: Rahila Syed
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.