Minor fixes for upcoming version 13
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,
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
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 messageBut 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
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
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