Re: BUG #14258: Documentation pl/pgsql
От | Дилян Палаузов |
---|---|
Тема | Re: BUG #14258: Documentation pl/pgsql |
Дата | |
Msg-id | 6d916240-3525-3116-e575-898d04238a8e@aegee.org обсуждение исходный текст |
Ответ на | Re: BUG #14258: Documentation pl/pgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #14258: Documentation pl/pgsql
("David G. Johnston" <david.g.johnston@gmail.com>)
Re: BUG #14258: Documentation pl/pgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Hello Tom, in you answer you have not tackled the argument, that the line with NOT NULL {DEFAULT | := | = } is soo long, that it doesfit 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@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 >
В списке pgsql-bugs по дате отправления: