Re: Documentation improvement patch

2024-09-13 Thread Oleg Sibiryakov

Here is a patch without the builtin/built-in corrections (find attached).

But I still believe the issue should be discussed further.
We actually have two options: it is either a spelling mistake (since 
built-in should written with a hyphen), or we miss the  tag 
(since it is actually also a value).


So I do think we cannot really leave it as is.

--
Oleg Sibiryakov

On 11.09.2024 12:53, Peter Eisentraut wrote:

On 10.09.24 15:02, Daniel Gustafsson wrote:
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.


I suspect that this would lead to the opposite confusion, people 
complaining that the provider is called "builtin" not "built-in".


Arguably, the other providers are also "built in".  There are no 
user-pluggable providers at this time.



diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index a63cc71efa2..7a905fd6a3a 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -8012,41 +8012,41 @@ SCRAM-SHA-256$:&l
for authentication
   
  
 
  
   
subrunasowner bool
   
   
If true, the subscription will be run with the permissions
of the subscription owner
   
  
 
  
   
subfailover bool
   
   
If true, the associated replication slots (i.e. the main slot and the
-   table sync slots) in the upstream database are enabled to be
+   table synchronization slots) in the upstream database are enabled to be
synchronized to the standbys
   
  
 
  
   
subconninfo text
   
   
Connection string to the upstream database
   
  
 
  
   
subslotname name
   
   
Name of the replication slot in the upstream database (also used
for the local replication origin name);
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index 834cb30c85a..a76e9579a14 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -365,59 +365,59 @@ initdb --locale-provider=icu --icu-locale=en
 Regardless of the locale provider, the operating system is still used to
 provide some locale-aware behavior, such as messages (see ).

 

 The available locale providers are listed below:

 

 
  builtin
  
   
The builtin provider uses built-in operations. Only
the C and C.UTF-8 locales are
supported for this provider.
   
   
The C locale behavior is identical to the
-   C locale in the libc provider. When using this
-   locale, the behavior may depend on the database encoding.
+   C locale in the libc provider. When
+   using this locale, the behavior may depend on the database encoding.
   
   
The C.UTF-8 locale is available only for when the
database encoding is UTF-8, and the behavior is
based on Unicode. The collation uses the code point values only. The
regular expression character classes are based on the "POSIX
Compatible" semantics, and the case mapping is the "simple" variant.
   
  
 
 
 
  icu
  
   
The icu provider uses the external
-   ICUICU
+   ICU
library. PostgreSQL must have been
configured with support.
   
   
ICU provides collation and character classification behavior that is
independent of the operating system and database encoding, which is
preferable if you expect to transition to other platforms without any
change in results. LC_COLLATE and
LC_CTYPE can be set independently of the ICU
locale.
   
   

 For the ICU provider, results may depend on the version of the ICU
 library used, as it is updated to reflect changes in natural language
 over time.

   
  
 
@@ -845,76 +845,77 @@ SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
 separate collate and ctype settings, so
 they are always the same.  Also, ICU collations are independent of the
 encoding, so there is always only one ICU collation of a given name in
 a database.

 

 Standard Collations
 

 On all platforms, the following collations are supported:
 
 
  
   unicode
   

 This SQL standard collation sorts using the Unicode Collation
 Algorithm with the Default Unicode Collation Element Table.  It is
 available in all encodings.  ICU support is required to use this
-collation, and behavior may change if Postgres is built with a
-

Re: Undocumented optionality of handler_statements

2024-09-13 Thread Philipp Salvisberg
>> 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.

I agree. Expressing the optionality in the synopsis/EBNF is the
better way. Therefore I suggest adding the optionality also for the 
"statements" in this section (43.6.8. Trapping Errors). And of course,
the optionality should be added for all related "statements" in other
sections such as 

- 43.2. Structure of PL/pgSQL
- 43.6.4.1. IF-THEN 
- 43.6.4.2. IF-THEN-ELSE
- 43.6.4.3. IF-THEN-ELSIF
- 43.6.4.4. Simple CASE
- 43.6.4.5. Searched CASE 
- 43.6.5.1. LOOP
- 43.6.5.4. WHILE
- 43.6.5.5. FOR (Integer Variant)
- 43.6.6. Looping through Query Results
- 43.6.7. Looping through Arrays
- 43.7.4. Looping through a Cursor's Result

The PL/pgSQL implementation allows empty branches.




Re: Undocumented optionality of handler_statements

2024-09-13 Thread David G. Johnston
On Friday, September 13, 2024, Philipp Salvisberg <
philipp.salvisb...@gmail.com> wrote:

> >> 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.
>
> I agree. Expressing the optionality in the synopsis/EBNF is the
> better way. Therefore I suggest adding the optionality also for the
> "statements" in this section (43.6.8. Trapping Errors). And of course,
> the optionality should be added for all related "statements" in other
> sections such as
>

This concept is already covered by:


https://www.postgresql.org/docs/16/plpgsql-statements.html#PLPGSQL-STATEMENTS-NULL

These placeholders indicate where a set of statements goes.  That set is
not optional.  The set can be empty - as documented at the link above -
though IMO it is better to encourage representing the empty set as the
one-element set with the NULL no-op statement.  I would make all our
examples use NULL and the reader, if finding an example of an empty-set in
the wild, can be pointed to the above section for confirmation that it is
not a bug.

David J.