Minor fixes for upcoming version 13

Started by Alexander Lakhinover 5 years ago5 messages
#1Alexander Lakhin
exclusion@gmail.com
1 attachment(s)

Hello hackers,

Please consider fixing minor defects in the source code and documentation.
1. a missing dot in guc.c
"SELECT name, short_desc FROM pg_settings WHERE short_desc NOT LIKE
'%.'" finds only this one instance.
2. inrange -> in_range
the former spelling is unique
3. sigature -> signature
4. "start timeline %u not found history of timeline %u" -> "start
timeline %u not found in history of timeline %u"
it seems that a preposition is missing
5. <type>BackgroundWorker *worker</type> -> <parameter>BackgroundWorker
*worker</parameter>
incorrect Docbook tag
6. "unhandled previous state in xqs" -> "unhandled previous state at end
quote"?
"xqs" is rather cryptic for a user-visible message

I'm not sure about 6, so the attached patch covers only 1-5.

Best regards,
Alexander

Attachments:

minor-fixes.patchtext/x-patch; charset=UTF-8; name=minor-fixes.patchDownload
diff --git a/doc/src/sgml/bgworker.sgml b/doc/src/sgml/bgworker.sgml
index 6e1cf121de0..1876dfbd5a5 100644
--- a/doc/src/sgml/bgworker.sgml
+++ b/doc/src/sgml/bgworker.sgml
@@ -34,11 +34,11 @@
   <productname>PostgreSQL</productname> is started by including the module name in
   <varname>shared_preload_libraries</varname>.  A module wishing to run a background
   worker can register it by calling
-  <function>RegisterBackgroundWorker(<type>BackgroundWorker *worker</type>)</function>
+  <function>RegisterBackgroundWorker(<parameter>BackgroundWorker *worker</parameter>)</function>
   from its <function>_PG_init()</function>.  Background workers can also be started
   after the system is up and running by calling the function
-  <function>RegisterDynamicBackgroundWorker(<type>BackgroundWorker
-  *worker, BackgroundWorkerHandle **handle</type>)</function>.  Unlike
+  <function>RegisterDynamicBackgroundWorker(<parameter>BackgroundWorker *worker</parameter>,
+  <parameter>BackgroundWorkerHandle **handle</parameter>)</function>.  Unlike
   <function>RegisterBackgroundWorker</function>, which can only be called from within
   the postmaster, <function>RegisterDynamicBackgroundWorker</function> must be
   called from a regular backend or another background worker.
diff --git a/doc/src/sgml/btree.sgml b/doc/src/sgml/btree.sgml
index d03ee4d6fa0..4a1ac40297c 100644
--- a/doc/src/sgml/btree.sgml
+++ b/doc/src/sgml/btree.sgml
@@ -263,7 +263,7 @@
    </listitem>
   </varlistentry>
   <varlistentry>
-   <term><function>inrange</function></term>
+   <term><function>in_range</function></term>
    <listitem>
     <indexterm>
      <primary>in_range support functions</primary>
diff --git a/doc/src/sgml/intarray.sgml b/doc/src/sgml/intarray.sgml
index 9d2eb52eeb4..956c01d7493 100644
--- a/doc/src/sgml/intarray.sgml
+++ b/doc/src/sgml/intarray.sgml
@@ -452,7 +452,7 @@
 -- a message can be in one or more <quote>sections</quote>
 CREATE TABLE message (mid INT PRIMARY KEY, sections INT[], ...);
 
--- create specialized index with sigature length of 32 bytes
+-- create specialized index with signature length of 32 bytes
 CREATE INDEX message_rdtree_idx ON message USING GIST (sections gist__int_ops(siglen=32));
 
 -- select messages in section 1 OR 2 - OVERLAP operator
diff --git a/src/backend/replication/backup_manifest.c b/src/backend/replication/backup_manifest.c
index b6260049271..a43c793e289 100644
--- a/src/backend/replication/backup_manifest.c
+++ b/src/backend/replication/backup_manifest.c
@@ -272,7 +272,7 @@ AddWALInfoToBackupManifest(backup_manifest_info *manifest, XLogRecPtr startptr,
 	 */
 	if (!found_start_timeline)
 		ereport(ERROR,
-				errmsg("start timeline %u not found history of timeline %u",
+				errmsg("start timeline %u not found in history of timeline %u",
 					   starttli, endtli));
 
 	/* Terminate the list of WAL ranges. */
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 20d4784b335..44c3e5051df 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -3133,7 +3133,7 @@ static struct config_int ConfigureNamesInt[] =
 	},
 	{
 		{"autovacuum_vacuum_insert_threshold", PGC_SIGHUP, AUTOVACUUM,
-			gettext_noop("Minimum number of tuple inserts prior to vacuum, or -1 to disable insert vacuums"),
+			gettext_noop("Minimum number of tuple inserts prior to vacuum, or -1 to disable insert vacuums."),
 			NULL
 		},
 		&autovacuum_vac_ins_thresh,
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Alexander Lakhin (#1)
Re: Minor fixes for upcoming version 13

Alexander Lakhin <exclusion@gmail.com> writes:

Please consider fixing minor defects in the source code and documentation.

I agree with all of these, except the markup fixes in bgworker.sgml
still seem not right; it should be more like

<function>RegisterBackgroundWorker(<type>BackgroundWorker</type> *<parameter>worker</parameter>)</function>

6. "unhandled previous state in xqs" -> "unhandled previous state at end
quote"?
"xqs" is rather cryptic for a user-visible message

But it's not user-visible is it? That should surely be a can't-happen
case.

Will push in a little bit.

regards, tom lane

#3Alexander Lakhin
exclusion@gmail.com
In reply to: Tom Lane (#2)
Re: Minor fixes for upcoming version 13

Hello Tom,

09.09.2020 18:29, Tom Lane wrote:

Alexander Lakhin <exclusion@gmail.com> writes:

Please consider fixing minor defects in the source code and documentation.

I agree with all of these, except the markup fixes in bgworker.sgml
still seem not right; it should be more like

<function>RegisterBackgroundWorker(<type>BackgroundWorker</type> *<parameter>worker</parameter>)</function>

Yes, but I've tried to minimize the change and align with the adjacent
text. For example:
<para>Once running, the process can connect to a database by calling
   <function>BackgroundWorkerInitializeConnection(<parameter>char
*dbname</parameter>...

6. "unhandled previous state in xqs" -> "unhandled previous state at end
quote"?
"xqs" is rather cryptic for a user-visible message

But it's not user-visible is it? That should surely be a can't-happen
case.

I've encountered this while translating NLS messages in postgres.po and
ecpg.po. So I think it should at least puzzle translators.

Best regards,
Alexander

#4John Naylor
john.naylor@2ndquadrant.com
In reply to: Alexander Lakhin (#3)
Re: Minor fixes for upcoming version 13

On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin <exclusion@gmail.com> wrote:

Hello Tom,

09.09.2020 18:29, Tom Lane wrote:

But it's not user-visible is it? That should surely be a can't-happen
case.

I've encountered this while translating NLS messages in postgres.po and
ecpg.po. So I think it should at least puzzle translators.

Maybe instead Assert(0) with a comment or something like that?

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: John Naylor (#4)
Re: Minor fixes for upcoming version 13

John Naylor <john.naylor@2ndquadrant.com> writes:

On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin <exclusion@gmail.com> wrote:

09.09.2020 18:29, Tom Lane wrote:

But it's not user-visible is it? That should surely be a can't-happen
case.

I've encountered this while translating NLS messages in postgres.po and
ecpg.po. So I think it should at least puzzle translators.

Maybe instead Assert(0) with a comment or something like that?

Maybe what we need is yyerror_internal() for messages that don't require
translation. Or just convert it to a plain elog(ERROR) ... that would
lose the possibility of providing an error cursor, but that seems like
something we don't need here either.

regards, tom lane