Re: BUG #14258: Documentation pl/pgsql

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