doc: Standardize use of dashes in references to CRC and SHA.
authorNathan Bossart <[email protected]>
Fri, 9 Aug 2024 18:16:33 +0000 (13:16 -0500)
committerNathan Bossart <[email protected]>
Fri, 9 Aug 2024 18:16:33 +0000 (13:16 -0500)
Presently, we inconsistently use dashes in references to these
algorithms (e.g., CRC32C versus CRC-32C).  Some popular web sources
appear to prefer dashes, and with this commit, we will, too.

Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan

doc/src/sgml/backup-manifest.sgml
doc/src/sgml/pgcrypto.sgml
doc/src/sgml/ref/pg_basebackup.sgml

index d5ec244834ec148297dd22c5cd3ce516a18eeb08..594e216bcba1f17c71499f546efc1ccbfe2e933a 100644 (file)
     <listitem>
      <para>
       This key is always present on the last line of the backup manifest file.
-      The associated value is a SHA256 checksum of all the preceding lines.
+      The associated value is a SHA-256 checksum of all the preceding lines.
       We use a fixed checksum method here to make it possible for clients
-      to do incremental parsing of the manifest. While a SHA256 checksum
-      is significantly more expensive than a CRC32C checksum, the manifest
+      to do incremental parsing of the manifest. While a SHA-256 checksum
+      is significantly more expensive than a CRC-32C checksum, the manifest
       should normally be small enough that the extra computation won't matter
       very much.
      </para>
index b8b89696e7f68ba43f13c015a1940952f2dbf3d5..396c67f0cdef2350c6c8d26d0a93ee8121a91e0a 100644 (file)
@@ -106,7 +106,7 @@ hmac(data bytea, key bytea, type text) returns bytea
 
   <para>
    The algorithms in <function>crypt()</function> differ from the usual
-   MD5 or SHA1 hashing algorithms in the following respects:
+   MD5 or SHA-1 hashing algorithms in the following respects:
   </para>
 
   <orderedlist>
@@ -525,7 +525,7 @@ gen_salt(type text [, iter_count integer ]) returns text
    </listitem>
    <listitem>
     <para>
-     A SHA1 hash of the random prefix and data is appended.
+     A SHA-1 hash of the random prefix and data is appended.
     </para>
    </listitem>
    <listitem>
index 82d0c8e0088d2441e9622e180c7e001acd39c628..4f99340c1dd8f323f39392678d9b5a85a44536f7 100644 (file)
@@ -687,7 +687,7 @@ PostgreSQL documentation
        <para>
         Using a SHA hash function provides a cryptographically secure digest
         of each file for users who wish to verify that the backup has not been
-        tampered with, while the CRC32C algorithm provides a checksum that is
+        tampered with, while the CRC-32C algorithm provides a checksum that is
         much faster to calculate; it is good at catching errors due to accidental
         changes but is not resistant to malicious modifications.  Note that, to
         be useful against an adversary who has access to the backup, the backup