doc: Standardize use of dashes in references to CRC and SHA.

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
This commit is contained in:
Nathan Bossart 2024-08-09 13:16:33 -05:00
parent 8c3548613d
commit 7fceb5725b
3 changed files with 6 additions and 6 deletions

View File

@ -87,10 +87,10 @@
<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>

View 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>

View 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