Re: Error message with plpgsql CONTINUE
От | Jim Nasby |
---|---|
Тема | Re: Error message with plpgsql CONTINUE |
Дата | |
Msg-id | 55D79283.1070005@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Error message with plpgsql CONTINUE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error message with plpgsql CONTINUE
|
Список | pgsql-hackers |
On 8/17/15 4:46 PM, Tom Lane wrote: > 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. 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
Вложения
В списке pgsql-hackers по дате отправления: