Read-only vs read only vs readonly
I had a customer point out to me that we're inconsistent in how we
spell read-only. Turns out we're not as inconsistent as I initially
thought :), but that they did manage to spot the one actual log
message we have that writes it differently than everything else -- but
that broke their grepping...
Almost everywhere we use read-only. Attached patch changes the one log
message where we didn't, as well as a few places in the docs for it. I
did not bother with things like comments in the code.
Two questions:
1. Is it worth fixing? Or just silly nitpicking?
2. What about translations? This string exists in translations --
should we just "fix" it there, without touching the translated string?
Or try to fix both? Or leave it for the translators who will get a
diff on it?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Attachments:
readonly.patchtext/x-patch; charset=US-ASCII; name=readonly.patchDownload
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 2b2c70a26e..2f0def9b19 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9602,7 +9602,7 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
</table>
<para>
- The <structname>pg_available_extensions</structname> view is read only.
+ The <structname>pg_available_extensions</structname> view is read-only.
</para>
</sect1>
@@ -9726,8 +9726,8 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
</table>
<para>
- The <structname>pg_available_extension_versions</structname> view is read
- only.
+ The <structname>pg_available_extension_versions</structname> view is
+ read-only.
</para>
</sect1>
@@ -10042,7 +10042,7 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
</table>
<para>
- The <structname>pg_cursors</structname> view is read only.
+ The <structname>pg_cursors</structname> view is read-only.
</para>
</sect1>
@@ -11164,7 +11164,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</table>
<para>
- The <structname>pg_prepared_statements</structname> view is read only.
+ The <structname>pg_prepared_statements</structname> view is read-only.
</para>
</sect1>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 22af7dbf51..c43f214020 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1093,7 +1093,7 @@ primary_slot_name = 'node_a_slot'
</para>
<para>
- Read only transactions and transaction rollbacks need not wait for
+ Read-only transactions and transaction rollbacks need not wait for
replies from standby servers. Subtransaction commits do not wait for
responses from standby servers, only top-level commits. Long
running actions such as data loading or index building do not wait
@@ -1962,7 +1962,7 @@ LOG: entering standby mode
... then some time later ...
LOG: consistent recovery state reached
-LOG: database system is ready to accept read only connections
+LOG: database system is ready to accept read-only connections
</programlisting>
Consistency information is recorded once per checkpoint on the primary.
@@ -2191,7 +2191,7 @@ HINT: You can then restart the server after making the necessary configuration
</para>
<para>
- Currently, temporary table creation is not allowed during read only
+ Currently, temporary table creation is not allowed during read-only
transactions, so in some cases existing scripts will not run correctly.
This restriction might be relaxed in a later release. This is
both an SQL Standard compliance issue and a technical issue.
@@ -2290,7 +2290,7 @@ HINT: You can then restart the server after making the necessary configuration
<para>
Full knowledge of running transactions is required before snapshots
can be taken. Transactions that use large numbers of subtransactions
- (currently greater than 64) will delay the start of read only
+ (currently greater than 64) will delay the start of read-only
connections until the completion of the longest running write transaction.
If this situation occurs, explanatory messages will be sent to the server log.
</para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index d358bbe4a6..cfdcb74221 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -526,7 +526,7 @@ ERROR: could not serialize access due to concurrent update
transaction sees a completely stable view of the database. However,
this view will not necessarily always be consistent with some serial
(one at a time) execution of concurrent transactions of the same level.
- For example, even a read only transaction at this level may see a
+ For example, even a read-only transaction at this level may see a
control record updated to show that a batch has been completed but
<emphasis>not</emphasis> see one of the detail records which is logically
part of the batch because it read an earlier revision of the control
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 9c2c98614a..63043ed8d1 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -5199,7 +5199,7 @@ sigusr1_handler(SIGNAL_ARGS)
PgStatPID = pgstat_start();
ereport(LOG,
- (errmsg("database system is ready to accept read only connections")));
+ (errmsg("database system is ready to accept read-only connections")));
/* Report status */
AddToDataDirLockFile(LOCK_FILE_LINE_PM_STATUS, PM_STATUS_READY);
On 9/2/21, 11:30 AM, "Magnus Hagander" <magnus@hagander.net> wrote:
I had a customer point out to me that we're inconsistent in how we
spell read-only. Turns out we're not as inconsistent as I initially
thought :), but that they did manage to spot the one actual log
message we have that writes it differently than everything else -- but
that broke their grepping...Almost everywhere we use read-only. Attached patch changes the one log
message where we didn't, as well as a few places in the docs for it. I
did not bother with things like comments in the code.Two questions:
1. Is it worth fixing? Or just silly nitpicking?
It seems entirely reasonable to me to consistently use "read-only" in
the log messages and documentation.
2. What about translations? This string exists in translations --
should we just "fix" it there, without touching the translated string?
Or try to fix both? Or leave it for the translators who will get a
diff on it?
I don't have a strong opinion, but if I had to choose, I would say to
leave it to the translators to decide.
Nathan
At Thu, 2 Sep 2021 22:07:02 +0000, "Bossart, Nathan" <bossartn@amazon.com> wrote in
On 9/2/21, 11:30 AM, "Magnus Hagander" <magnus@hagander.net> wrote:
I had a customer point out to me that we're inconsistent in how we
spell read-only. Turns out we're not as inconsistent as I initially
thought :), but that they did manage to spot the one actual log
message we have that writes it differently than everything else -- but
that broke their grepping...Almost everywhere we use read-only. Attached patch changes the one log
message where we didn't, as well as a few places in the docs for it. I
did not bother with things like comments in the code.Two questions:
1. Is it worth fixing? Or just silly nitpicking?
It seems entirely reasonable to me to consistently use "read-only" in
the log messages and documentation.2. What about translations? This string exists in translations --
should we just "fix" it there, without touching the translated string?
Or try to fix both? Or leave it for the translators who will get a
diff on it?I don't have a strong opinion, but if I had to choose, I would say to
leave it to the translators to decide.
+1 for both. As a translator, it seems that that kind of changes are
usual. Many changes about full-stops, spacings, capitalizing and so
happen especially at near-release season like now.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Fri, Sep 3, 2021 at 8:10 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
At Thu, 2 Sep 2021 22:07:02 +0000, "Bossart, Nathan" <bossartn@amazon.com> wrote in
On 9/2/21, 11:30 AM, "Magnus Hagander" <magnus@hagander.net> wrote:
I had a customer point out to me that we're inconsistent in how we
spell read-only. Turns out we're not as inconsistent as I initially
thought :), but that they did manage to spot the one actual log
message we have that writes it differently than everything else -- but
that broke their grepping...Almost everywhere we use read-only. Attached patch changes the one log
message where we didn't, as well as a few places in the docs for it. I
did not bother with things like comments in the code.Two questions:
1. Is it worth fixing? Or just silly nitpicking?
It seems entirely reasonable to me to consistently use "read-only" in
the log messages and documentation.2. What about translations? This string exists in translations --
should we just "fix" it there, without touching the translated string?
Or try to fix both? Or leave it for the translators who will get a
diff on it?I don't have a strong opinion, but if I had to choose, I would say to
leave it to the translators to decide.+1 for both. As a translator, it seems that that kind of changes are
usual. Many changes about full-stops, spacings, capitalizing and so
happen especially at near-release season like now.
Thanks for the input. I've applied this and back-patched to 14 since
it's not out yet and there is translation still do be done. I didn't
backpatch it further back than that to avoid the need for translation
updates there.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/