Fix inaccurate mention of index comments in CREATE FOREIGN TABLE docs
Hi, Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE. In this feature, since indexes are not created for foreign tables, comments on indexes are not copied either. However, the CREATE FOREIGN TABLE docs incorrectly states that index comments are copied when using INCLUDING COMMENTS, as shown below: -- INCLUDING COMMENTS Comments for the copied columns, constraints, and indexes will be copied. -- This isn't accurate for foreign tables, so we should remove the mention of indexes. Patch attached. Regards, -- Fujii Masao NTT DATA Japan Corporation From e6a023b56f790c9995463d75e6101e5eaf49e98b Mon Sep 17 00:00:00 2001 From: Fujii Masao Date: Wed, 18 Jun 2025 13:56:14 +0900 Subject: [PATCH v1] doc: Fix incorrect description of INCLUDING COMMENTS in CREATE FOREIGN TABLE. Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE. In this feature, since indexes are not created for foreign tables, comments on indexes are not copied either. However, the documentation incorrectly stated that index comments would be copied when using INCLUDING COMMENTS. This commit corrects that by removing the mention of index comments. --- doc/src/sgml/ref/create_foreign_table.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index d08834ac9d2..009fa46532b 100644 --- a/doc/src/sgml/ref/create_foreign_table.sgml +++ b/doc/src/sgml/ref/create_foreign_table.sgml @@ -232,7 +232,7 @@ WITH ( MODULUS numeric_literal, REM INCLUDING COMMENTS - Comments for the copied columns, constraints, and indexes will be + Comments for the copied columns and constraints will be copied. The default behavior is to exclude comments, resulting in the copied columns and constraints in the new table having no comments. -- 2.49.0
Re: Fix inaccurate mention of index comments in CREATE FOREIGN TABLE docs
On Wed, Jun 18, 2025 at 02:34:55PM +0900, Fujii Masao wrote: > Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE. > In this feature, since indexes are not created for foreign tables, > comments on indexes are not copied either. Good point. This doc fix sounds fine to me. -- Michael signature.asc Description: PGP signature
Re: Clarify VACUUM FULL exclusion in total_vacuum_time docs
On 2025/06/13 21:09, Robert Treat wrote: Well, I admit I mostly mentioned it because when I noticed this one wasn't documented the same way the other ones were, I second-guessed myself about if I knew how it really behaved and did a quick test to confirm :-) I suspect others might have similar confusion. Maybe I failed to follow your point here... Are you suggesting it's worth mentioning that n_ins_since_vacuum doesn't count VACUUM FULL, to help avoid potential user confusion? If so, since n_ins_since_vacuum was introduced in v13, we'd need to backpatch that documentation change to v13? As for total_vacuum_time, since it's new in v18, I'd like to apply the proposed change there. Regards, -- Fujii Masao NTT DATA Japan Corporation
Reorder min/max_protocol_version descriptions in libpq documentation
Hi, Commit 285613c60a7 added the min_protocol_version and max_protocol_version connection options to libpq. However, their descriptions currently appear in the middle of the unrelated ssl_min_protocol_version and ssl_max_protocol_version entries in libpq.sgml. Is there a reason for this placement? To make the documentation more intuitive and easier to navigate, I suggest moving these entries after the SSL-related options. Attached is a patch that does that. Thanks, -- Fujii Masao NTT DATA Japan Corporation From de4ba3e771840024f07b5132baddeeb1dd611709 Mon Sep 17 00:00:00 2001 From: Fujii Masao Date: Wed, 18 Jun 2025 01:09:06 +0900 Subject: [PATCH v1] doc: Reorder protocol version option descriptions in libpq docs. Commit 285613c60a7 introduced the min_protocol_version and max_protocol_version connection options for libpq, but their descriptions were placed in the middle of the unrelated ssl_min_protocol_version and ssl_max_protocol_version entries. This commit moves the min_protocol_version and max_protocol_version descriptions to appear after the SSL-related options. This improves the logical order and makes it easier for users to locate the relevant settings in the libpq documentation. --- doc/src/sgml/libpq.sgml | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 695fe958c3e..08bd5121926 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -2168,6 +2168,24 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname + + ssl_max_protocol_version + + +This parameter specifies the maximum SSL/TLS protocol version to allow +for the connection. Valid values are TLSv1, +TLSv1.1, TLSv1.2 and +TLSv1.3. The supported protocols depend on the +version of OpenSSL used, older versions +not supporting the most modern protocol versions. If not set, this +parameter is ignored and the connection will use the maximum bound +defined by the backend, if set. Setting the maximum protocol version +is mainly useful for testing or if some component has issues working +with a newer protocol. + + + + min_protocol_version @@ -2216,24 +2234,6 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname - - ssl_max_protocol_version - - -This parameter specifies the maximum SSL/TLS protocol version to allow -for the connection. Valid values are TLSv1, -TLSv1.1, TLSv1.2 and -TLSv1.3. The supported protocols depend on the -version of OpenSSL used, older versions -not supporting the most modern protocol versions. If not set, this -parameter is ignored and the connection will use the maximum bound -defined by the backend, if set. Setting the maximum protocol version -is mainly useful for testing or if some component has issues working -with a newer protocol. - - - - krbsrvname -- 2.49.0
Re: Reorder min/max_protocol_version descriptions in libpq documentation
On Tue, 17 Jun 2025 at 18:32, Fujii Masao wrote: > > Hi, > > Commit 285613c60a7 added the min_protocol_version and max_protocol_version > connection options to libpq. However, their descriptions currently appear > in the middle of the unrelated ssl_min_protocol_version and > ssl_max_protocol_version entries in libpq.sgml. Is there a reason for > this placement? Not that I can remember, probably because I copied the ssl_min_protocol_version section when writing the initial version min_protocol_version section. > To make the documentation more intuitive and easier to navigate, > I suggest moving these entries after the SSL-related options. > Attached is a patch that does that. +1
Re: Reorder min/max_protocol_version descriptions in libpq documentation
On 2025/06/18 1:34, Jelte Fennema-Nio wrote: On Tue, 17 Jun 2025 at 18:32, Fujii Masao wrote: Hi, Commit 285613c60a7 added the min_protocol_version and max_protocol_version connection options to libpq. However, their descriptions currently appear in the middle of the unrelated ssl_min_protocol_version and ssl_max_protocol_version entries in libpq.sgml. Is there a reason for this placement? Not that I can remember, probably because I copied the ssl_min_protocol_version section when writing the initial version min_protocol_version section. To make the documentation more intuitive and easier to navigate, I suggest moving these entries after the SSL-related options. Attached is a patch that does that. +1 I've pushed the patch. Thanks! Regards, -- Fujii Masao NTT DATA Japan Corporation
Re: Clarify VACUUM FULL exclusion in total_vacuum_time docs
On Tue, Jun 17, 2025 at 10:54 AM Fujii Masao wrote: > On 2025/06/13 21:09, Robert Treat wrote: > > Well, I admit I mostly mentioned it because when I noticed this one > > wasn't documented the same way the other ones were, I second-guessed > > myself about if I knew how it really behaved and did a quick test to > > confirm :-) > > I suspect others might have similar confusion. > > Maybe I failed to follow your point here... Are you suggesting it's worth > mentioning that n_ins_since_vacuum doesn't count VACUUM FULL, to help > avoid potential user confusion? If so, since n_ins_since_vacuum was > introduced in v13, we'd need to backpatch that documentation change to v13? > > As for total_vacuum_time, since it's new in v18, I'd like to apply > the proposed change there. > I think the more cases where you document this behavior (and I do like the idea of documenting it for total_vacuum_time), the more one is likely to think that places where it is not documented operate differently. To that end, I think documenting it for n_ins_since_vacuum as well is a good idea, but I don't feel strongly that it needs to be backpatched; the old documentation wasn't wrong per se, rather this is a documentation improvement as a result of new development. Robert Treat https://xzilla.net
