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

From Pavel Stehule
Subject Re: Error message with plpgsql CONTINUE
Date
Msg-id CAFj8pRAy4zjknnubFE0qhqT77ikJGZ2x1d98GGSDrweLVB0T7Q@mail.gmail.com
Whole thread Raw
In response to Re: Error message with plpgsql CONTINUE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error message with plpgsql CONTINUE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi

2015-08-17 23:46 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
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.

when I implemented this check in plpgsql_check I found another minor issue in CONTINUE statement - the typename is wrong

Regards

Pavel



 

                        regards, tom lane


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: WIP: SCRAM authentication
Next
From: Merlin Moncure
Date:
Subject: Re: Autonomous Transaction is back