dpa-postgres@aegee.org writes:
> in doc/src/sgml/plpgsql.sgml please replace:
> ...
> because NOT NULL can be used only with {DEFAULT | := | =}.
I'm disinclined to do that; it's not required by the plpgsql grammar,
and in principle it might not be required at runtime either. In
particular, if the variable is of a domain type it would be sensible for
plpgsql to adopt the domain's default value if any.
> For GET [CURRENT] DIAGNOSITCS (plpgsql.sgml, line 1441) the documentation
> within pgpgsql.sgml is unclear, what is CURRENT supposed to do.
Hmm, it's just a noise word, but I agree the docs ought to say that.
> In <sect2 id="plpgsql-conditionals">, 1834 is written
> IF ... THEN
> CASE ... WHEN ... END CASE
> More consistent would be to write IF ... THEN ... END IF
Makes sense.
> In Trigger Procedures, Triggers on Data Changes is stated, that the return
> value of a row-level trigger is ignored. Does such a trigger have to
> execute explicitly RETURN, contrary to functions returning void?
Yes, I believe so; the documentation for RETURN does not make any
exception for triggers.
> In the example afterwards "A PL/pgSQL Trigger Procedure For Auditing", in
> process_emp_audit() as AFTER trigger, the comment states, that the return
> value is ignored, but why does the function have four return statements
> instead of just one?
[ shrug... ] Seems like reasonable coding style to me; for one thing,
it would make it easier to copy-and-paste the example as a basis for a
BEFORE trigger. I probably wouldn't have written it that way myself,
but I don't feel a need to change it.
> In subsection "Triggers on Events" please replace "is called as a event
> trigger" with "is called as AN event trigger".
Good catch, looks like there's a couple of those...
Thanks for the notes!
regards, tom lane