On 8/17/15 4:46 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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.
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. 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com