Re: Undocumented optionality of handler_statements

>> Therefore, I suggest to change this example by adding a NULL
>> statement as in other examples. This change would make the
>> documentation consistent and handle the optionality of
>> handler_statements as an implementation detail. I created a patch
>> for plpgsql.sgml based on the master branch, adding a NULL statement
>> in empty exception handlers (see attached file
>> doc_patch_using_null_stmt_instead_of_empty_exception_handler_v1.diff).
>
> These examples have been around for 20 years with, and I think that it
> is helpful to show this pattern as well. So if I were to do something
> about that, I would suggest the attached.

I agree. Expressing the optionality in the synopsis/EBNF is the
better way. Therefore I suggest adding the optionality also for the
"statements" in this section (43.6.8. Trapping Errors). And of course,
the optionality should be added for all related "statements" in other
sections such as

- 43.2. Structure of PL/pgSQL
- 43.6.4.1. IF-THEN
- 43.6.4.2. IF-THEN-ELSE
- 43.6.4.3. IF-THEN-ELSIF
- 43.6.4.4. Simple CASE
- 43.6.4.5. Searched CASE
- 43.6.5.1. LOOP
- 43.6.5.4. WHILE
- 43.6.5.5. FOR (Integer Variant)
- 43.6.6. Looping through Query Results
- 43.6.7. Looping through Arrays
- 43.7.4. Looping through a Cursor's Result

The PL/pgSQL implementation allows empty branches.