Re: Documentation improvement patch
Thank you for your feedback. 1. Since we do not want to use here, I suggest we hyphenate it as "built-in". What's your take on it? 2. Leaving not-null is fine. -- Oleg Sibiryakov On 06.09.2024 16:20, Daniel Gustafsson wrote: On 5 Sep 2024, at 11:33, Oleg Sibiryakov wrote: Dear all, I have prepared a patch containing some minor inconsistencies in the documentation. Please, take a look. The inconsistencies were noticed by: Ekaterina Kiryanova, Elena Indrupskaya, Maxim Yablokov, Anna Uraskova, Elena Karavaeva, and me. We will be looking forward to your feedback. The patch shall be applied to the REL_17_STABLE branch. Most of these seem fine, but I need another read-through to digest them fully. Just a few small comments: -Specifies the builtin provider locale for the database default -collation order and character classification, overriding the setting -. The builtin provider locale for the database +default collation order and character classification, overriding the +setting . The . +Specifies the locale name when the builtin provider +is used. Locale support is described in . I don't think this use of "builtin" refers to the config value but rather the type of locale, so I think it's correct to not use here. -for not-null constraints at all, so they are not +for NOT NULL constraints at all, so they are not This seems mostly to be a question of taste, I don't think not-null is incorrect here. -- Daniel Gustafsson
Re: Documentation improvement patch
> On 10 Sep 2024, at 13:46, Oleg Sibiryakov wrote: > 1. Since we do not want to use here, I suggest we hyphenate it as > "built-in". What's your take on it? I think that's the right choice given the hyphenation used in the rest of the docs. There are a few more places on that same page which should be built-in rather than builtin to separate the concept from the parameter value. -- Daniel Gustafsson
Re: Table rewrite supporting functions for event triggers
On Tue, Sep 03, 2024 at 09:34:02PM +0200, Laurenz Albe wrote: > On Tue, 2024-09-03 at 11:54 -0400, Greg Sabino Mullane wrote: >> How about something like this? > > This patch looks good to me. -Returns a code explaining the reason(s) for rewriting. The exact -meaning of the codes is release dependent. +Returns a code explaining the reason(s) for rewriting. The value is +a bitmap built from the following values: 1 (the table has changed +persistence), 2 (a column has changed a default value), 4 (a column +has a new data type), and 8 (the table access method has changed). Agreed that the user experience with this function is poor and that the documentation should be improved. Still, I am not sure that this is optimal. On top of the values, how about adding the variable names and also mention that these are defined in event_trigger.h? Putting the documentation change aside for a bit, could it be better to redesign this function and return a text value rather than an integer? We could directly return the names, minus "AT_REWRITE_", for instance. -- Michael signature.asc Description: PGP signature
Re: Undocumented optionality of handler_statements
On Tue, Jul 23, 2024 at 01:25:39PM +0200, Philipp Salvisberg wrote: > read "optional" as "mandatory". They're optional, like in empty being optional. If not specified, the block goes to its END. > 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. -- Michael diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index 78e4983139..3a5e7bc296 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -2804,9 +2804,9 @@ BEGIN statements EXCEPTION WHEN condition OR condition ... THEN -handler_statements + handler_statements WHEN condition OR condition ... THEN - handler_statements + handler_statements ... END; @@ -2821,8 +2821,8 @@ END; abandoned, and control passes to the EXCEPTION list. The list is searched for the first condition matching the error that occurred. If a match is found, the - corresponding handler_statements are - executed, and then control passes to the next statement after + corresponding handler_statements, if + specified are executed, and then control passes to the next statement after END. If no match is found, the error propagates out as though the EXCEPTION clause were not there at all: the error can be caught by an enclosing block with signature.asc Description: PGP signature
