Re: BUG #14258: Documentation pl/pgsql

Hello Tom,

in you answer you have not tackled the argument, that the line with NOT NULL {DEFAULT | := | = } is soo long, that it does fit in its current form in the PDF provided documentation: https://www.postgresql.org/files/documentation/pdf/9.5/postgresql-9.5-A4.pdf, page logical 1063(physical 1138).

On which occasions is the online documentation regenerated (in terms of https://www.postgresql.org/docs/9.5/static/, https://www.postgresql.org/docs/9.4/static/ and https://www.postgresql.org/files/documentation/pdf/9.5/postgresql-9.5-A4.pdf ) from the .sgml files?

Greetings
Dilian

On 07/18/2016 09:29 PM, Tom Lane wrote:
> dpa-postgres(at)aegee(dot)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
>