mirror of
https://github.com/postgres/postgres.git
synced 2025-06-06 00:02:36 -04:00
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:
parent
8c3548613d
commit
7fceb5725b
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user