[taler-docs] branch master updated: s/Postgres/PostgreSQL/g

[gnunet]

This is an automated email from the git hooks/post-receive script.

ttn pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new b6b96ee  s/Postgres/PostgreSQL/g
b6b96ee is described below

commit b6b96eebb81ff3daecced9b43218ba8eb3268cce
Author: Thien-Thi Nguyen <ttn@gnuvola.org>
AuthorDate: Thu Jan 6 15:56:00 2022 -0500

    s/Postgres/PostgreSQL/g
---
 design-documents/010-exchange-helpers.rst |  6 +++---
 design-documents/011-auditor-db-sync.rst  |  8 ++++----
 manpages/sync-config.1.rst                |  2 +-
 manpages/taler-config.1.rst               |  2 +-
 taler-auditor-manual.rst                  | 28 ++++++++++++++--------------
 taler-developer-manual.rst                |  2 +-
 taler-exchange-manual.rst                 | 10 +++++-----
 taler-exchange-setup-guide.rst            |  2 +-
 taler-merchant-manual.rst                 | 22 +++++++++++-----------
 9 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/design-documents/010-exchange-helpers.rst 
b/design-documents/010-exchange-helpers.rst
index e67fca4..a12b4a2 100644
--- a/design-documents/010-exchange-helpers.rst
+++ b/design-documents/010-exchange-helpers.rst
@@ -13,7 +13,7 @@ Motivation
 
 We want to provide an additional layer of protection for the private online
 signing keys used by the exchange. The exchange is network-facing, includes an
-HTTP server, Postgres interaction, JSON parser and quite a bit of other logic
+HTTP server, PostgreSQL interaction, JSON parser and quite a bit of other logic
 which may all be theoretically vulnerable to remote exploitation.  Thus, it
 would be good from a security perspective to protect the private online
 signing keys via an additional layer of protection.
@@ -89,7 +89,7 @@ Exchange design considerations:
   exchange. This simplifies the exchange, and we already needed the
   exchange operator to start four processes to operate an exchange.
   So this number simply increases to six (not even counting the
-  Postgres database and a reverse HTTP proxy for TLS termination).
+  PostgreSQL database and a reverse HTTP proxy for TLS termination).
 * Each exchange thread will create its own connection to the helpers, and will
   block while waiting on the helper to create a signature.  This keeps the
   exchange logic simple and similar to the existing in-line signing calls.
@@ -108,7 +108,7 @@ New exchange endpoints:
   sign based on that file, and then upload the resulting signature back to
   the exchange. For this, master signatures will be POSTed to
   the exchange to the ``/keys`` endpoint.
-  The exchange will keep those signatures in the Postgres database.
+  The exchange will keep those signatures in the PostgreSQL database.
 * A new endpoint (``/auditors``) will also allow adding/removing auditors
   (POST, DELETE) using requests signed with the offline master private key.
   Once an auditor has been added, the respective auditor signatures on exchange
diff --git a/design-documents/011-auditor-db-sync.rst 
b/design-documents/011-auditor-db-sync.rst
index f8229b6..d49503d 100644
--- a/design-documents/011-auditor-db-sync.rst
+++ b/design-documents/011-auditor-db-sync.rst
@@ -89,9 +89,9 @@ Proposed Solution
 * The auditor's "ingress" database should be well isolated from
   the rest of the auditor's system and database
   (different user accounts). The reason is that we should not
-  assume that the Postgres replication code is battle-tested with
+  assume that the PostgreSQL replication code is battle-tested with
   malicious parties in mind.
-* The canonical Postgres synchronization between exchange and the
+* The canonical PostgreSQL synchronization between exchange and the
   auditor's "ingress" database must use transport security.
 
 The above solution does not gracefully handle mutable tables on which
@@ -148,10 +148,10 @@ A good order for replicating the tables should be:
 Alternatives
 ============
 
-* Copy the Postgres WAL, filter it for "illegal" operations
+* Copy the PostgreSQL WAL, filter it for "illegal" operations
   and then apply it at the auditor end.  Disadvantages: WAL
   filtering is not a common operation (format documented?),
-  this would be highly Postgres-specific, and would require
+  this would be highly PostgreSQL-specific, and would require
   complex work to write the filter.  Also unsure how one
   could later recover gracefully from transient errors
   (say where the exchange recified a bogus DELETE).
diff --git a/manpages/sync-config.1.rst b/manpages/sync-config.1.rst
index 14c61a0..c7dd9ea 100644
--- a/manpages/sync-config.1.rst
+++ b/manpages/sync-config.1.rst
@@ -35,7 +35,7 @@ Description
 **-b** *BACKEND* \| **--supported-backend=**\ \ *BACKEND*
     Tests whether the specified *BACKEND* is supported by the current 
installation.
     The backend must match the name of a plugin, i.e. "namestore_postgres" for
-    the Postgres database backend of the "NAMESTORE" service.  If *BACKEND* is
+    the PostgreSQL database backend of the "NAMESTORE" service.  If *BACKEND* 
is
     supported, sync-config will return a status code of 0 (success), otherwise
     77 (unsupported).  When this option is specified, no other options may be
     specified. Specifying this option together with other options will cause
diff --git a/manpages/taler-config.1.rst b/manpages/taler-config.1.rst
index 103c95e..14a8959 100644
--- a/manpages/taler-config.1.rst
+++ b/manpages/taler-config.1.rst
@@ -35,7 +35,7 @@ Description
 **-b** *BACKEND* \| **--supported-backend=**\ \ *BACKEND*
     Tests whether the specified *BACKEND* is supported by the current 
installation.
     The backend must match the name of a plugin, i.e. "namestore_postgres" for
-    the Postgres database backend of the "NAMESTORE" service.  If *BACKEND* is
+    the PostgreSQL database backend of the "NAMESTORE" service.  If *BACKEND* 
is
     supported, taler-config will return a status code of 0 (success), otherwise
     77 (unsupported).  When this option is specified, no other options may be
     specified. Specifying this option together with other options will cause
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index cf3952f..e7aecb8 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -65,7 +65,7 @@ all, the goal is to detect nerfarious activity of the 
exchange operator,
 which cannot be effectively done on a machine controlled by the exchange
 operator.
 
-For this, every auditor needs to operate a Postgres database.  The data
+For this, every auditor needs to operate a PostgreSQL database.  The data
 collected will include sensitive information about Taler users, including
 withdrawals made by consumers and income received by merchants.  As a result,
 the auditor is expected to provide high confidentiality for the database.  In
@@ -118,7 +118,7 @@ third parties to verify one's own work.
 The Taler software stack for an auditor consists of the following
 components:
 
--  DBMS: Postgres
+-  DBMS: PostgreSQL
 
    The auditor requires a DBMS to store a local copy of the transaction 
history for
    the Taler exchange, as well as for its own internal bookkeeping and 
checkpointing.
@@ -128,7 +128,7 @@ components:
    concern that must be addressed manually.  The software only verifies the 
content
    of a well-formed exchange database (well-formed with respect to SQL).
    For now, the GNU Taler reference implementation
-   only supports Postgres, but the code could be easily extended to
+   only supports PostgreSQL, but the code could be easily extended to
    support another DBMS.
 
 -  The auditor Web service
@@ -268,7 +268,7 @@ Additionally, there are two canonical system users of 
relevance (which your
 distribution would typically create for you):
 
   * www-data --- runs the HTTPS frontend (usually nginx or Apache)
-  * postgres --- runs the Postgres database
+  * postgres --- runs the PostgreSQL database
 
 
 Databases and users
@@ -585,7 +585,7 @@ as illustrated in the following figure:
 
 .. image:: replication.png
 
-First, the exchange should use standard Postgres replication features to
+First, the exchange should use standard PostgreSQL replication features to
 enable the auditor to obtain a full copy of the exchange's database.
 Second, the auditor should make a "trusted" local copy, ensuring that it
 never replicates malicious changes using ``taler-auditor-sync``. Both
@@ -595,7 +595,7 @@ We note that as a result of these steps, the auditor will 
have three
 databases: its own production primary database (as configured in
 ``auditordb-postgres``), its on production copy of the exchange's database
 (``exchangedb-postgress``), and a third, untrusted "ingres" copy of the
-exchange database.  The untrusted database should run as a separate Postgres
+exchange database.  The untrusted database should run as a separate PostgreSQL
 instance and is only accessed via ``taler-auditor-sync`` and the replication
 mechanism driven by the exchange operator.
 
@@ -607,7 +607,7 @@ Ingres operation should be done using the 
``auditor-ingres`` user --- or
 depending on the setup parts of the operation may be done by the ``postgres``
 user directly.
 
-The full copy can be obtained in various ways with Postgres.  It is
+The full copy can be obtained in various ways with PostgreSQL.  It is
 possible to use log shipping with streaming replication as described
 in https://www.postgresql.org/docs/13/warm-standby.html, or to use
 logical replication, as described in
@@ -616,7 +616,7 @@ that asynchronous replication should suffice.
 
 The resulting auditor database should be treated as read-only on the auditor
 side.  The ``taler-exchange-dbinit`` tool can be used to setup the schema, or
-the schema can be replicated using Postgres's standard mechanisms. The same
+the schema can be replicated using PostgreSQL's standard mechanisms. The same
 applies for schema upgrades: if logical replication is used (which does not
 replicate schema changes), ``taler-exchange-dbinit`` can be used to migrate
 the schema(s) in both the ingres and production copies of the exchange's
@@ -640,7 +640,7 @@ Wireguard.
 It is also necessary to edit ``main.cf`` of the exchange and on the auditor
 side to enable logical replication.  If an exchange has multiple auditors, it
 should setup multiple ``egress`` accounts.  The exchange must ensure that
-the following lines are in the ``main.cf`` Postgres configuration (the port
+the following lines are in the ``main.cf`` PostgreSQL configuration (the port
 may differ) to enable replication over the network:
 
 .. code-block::
@@ -650,7 +650,7 @@ may differ) to enable replication over the network:
    wal_level= logical
 
 Equally, the auditor must configure logical replication in the ``main.cf``
-Postgres configuration:
+PostgreSQL configuration:
 
 .. code-block::
 
@@ -677,7 +677,7 @@ system must subscribe:
    $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange
 
 
-For details, we refer to the Postgres manual.
+For details, we refer to the PostgreSQL manual.
 
 .. note::
 
@@ -686,9 +686,9 @@ For details, we refer to the Postgres manual.
    ``DROP`` operations on the tables.  Hence, the auditor cannot rely upon the
    exchange's primary copy to respect schema constraints, especially as we
    have to presume that the exchange could act maliciously.  Furthermore, it
-   is unclear to what degree Postgres database replication mechanisms are
+   is unclear to what degree PostgreSQL database replication mechanisms are
    robust against a malicious master database.  Thus, the auditor should
-   isolate its primary copy of the exchange database, including the Postgres
+   isolate its primary copy of the exchange database, including the PostgreSQL
    process, from its actual operational data.
 
 
@@ -708,7 +708,7 @@ While ``taler-auditor-sync`` could in theory be run 
directly against the
 exchange's production system, this is likely a bad idea due to the high
 latency from the network between auditor and exchange operator. Thus, we
 recommend first making an "untrusted" ingress copy of the exchange's
-production database using standard Postgres tooling, and then using
+production database using standard PostgreSQL tooling, and then using
 ``taler-auditor-sync`` to create a second "safe" copy.  The "safe" copy used
 by the production system should also run under a different UID.
 
diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst
index ae99e7a..b7f2ac4 100644
--- a/taler-developer-manual.rst
+++ b/taler-developer-manual.rst
@@ -504,7 +504,7 @@ prepared.
 Database schema versioning
 --------------------------
 
-The Postgres databases of the exchange and the auditor are versioned.
+The PostgreSQL databases of the exchange and the auditor are versioned.
 See the 0000.sql file in the respective directory for documentation.
 
 Every set of changes to the database schema must be stored in a new
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 7beb7fb..a957447 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -63,7 +63,7 @@ etc.).  This manual will not cover these aspects of operating 
a
 payment service provider.
 
 We will assume that you can operate a (high-availability,
-high-assurance) Postgres database. Furthermore, we expect some moderate
+high-assurance) PostgreSQL database. Furthermore, we expect some moderate
 familiarity with the compilation and installation of free software
 packages. You need to understand the cryptographic concepts of private
 and public keys and must be able to protect private keys stored in files
@@ -181,9 +181,9 @@ components:
    The exchange requires a DBMS to stores the transaction history for
    the Taler exchange and aggregator, and a (typically separate) DBMS
    for the Taler auditor. For now, the GNU Taler reference implementation
-   only supports Postgres, but the code could be easily extended to
+   only supports PostgreSQL, but the code could be easily extended to
    support another DBMS.
-   .. index:: Postgres
+   .. index:: PostgreSQL
 
 -  Auditor
    The auditor verifies that the transactions performed by the exchange
@@ -787,7 +787,7 @@ they should use the same configuration file.
 
 For the most secure deployment, we recommend using separate users for each of
 these processes to minimize information disclosures should any of them be
-compromised.  The helpers do not need access to the Postgres database (and
+compromised.  The helpers do not need access to the PostgreSQL database (and
 thus also should not have it).
 
 The processes that require access to the bank account need to have a
@@ -1066,4 +1066,4 @@ repetitions (i.e. if the operation failed the first 
time), total execution
 time (operating system and user space) and other details.
 
 Naturally, additional instrumentation (including using features of the
-Postgres database itself) may help discover performance issues.
+PostgreSQL database itself) may help discover performance issues.
diff --git a/taler-exchange-setup-guide.rst b/taler-exchange-setup-guide.rst
index 1cac1f9..ab028ee 100644
--- a/taler-exchange-setup-guide.rst
+++ b/taler-exchange-setup-guide.rst
@@ -164,7 +164,7 @@ to compartmentalize different parts of the system:
 * ``taler-exchange-closer``: closes idle reserves by triggering wire transfers 
that refund the originator.
 * ``taler-exchange-aggregator``: aggregates deposits into larger wire transfer 
requests.
 * ``taler-exchange-wire``: performs wire transfers with the bank (via 
LibEuFin/Nexus).
-* ``postgres``: runs the Postgres database (from *postgres* package).
+* ``postgres``: runs the PostgreSQL database (from *postgres* package).
 * ``www-data``: runs the frontend HTTPS service with the TLS keys (from 
*nginx* package).
 
 .. note::
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 08663d5..f568ef1 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -66,7 +66,7 @@ special currency “KUDOS” and includes its own special bank.
 .. index:: back-office
 .. index:: backend
 .. index:: DBMS
-.. index:: Postgres
+.. index:: PostgreSQL
 
 The Taler software stack for a merchant consists of four main
 components:
@@ -90,8 +90,8 @@ components:
    describes how to install and configure this backend.
 -  A *DBMS* which stores the transaction history for the Taler backend.
    For now, the GNU Taler reference implementation only supports
-   Postgres, but the code could be easily extended to support another
-   DBMS.  Please review the Postgres documentation for details on
+   PostgreSQL, but the code could be easily extended to support another
+   DBMS.  Please review the PostgreSQL documentation for details on
    how to configure the database.
 
 The following image illustrates the various interactions of these key
@@ -475,7 +475,7 @@ Backend options
 ---------------
 
 .. index:: DBMS
-.. index:: Postgres
+.. index:: PostgreSQL
 .. index:: UNIX domain socket
 .. index:: TCP
 .. index:: port
@@ -596,7 +596,7 @@ For the ``postgres`` backend, you need to provide:
 
 This option specifies a postgres access path using the format
 ``postgres:///$DBNAME``, where ``$DBNAME`` is the name of the
-Postgres database you want to use. Suppose ``$USER`` is the name of
+PostgreSQL database you want to use. Suppose ``$USER`` is the name of
 the user who will run the backend process. Then, you need to first
 run:
 
@@ -604,7 +604,7 @@ run:
 
    $ sudo -u postgres createuser -d $USER
 
-as the Postgres database administrator (usually ``postgres``) to
+as the PostgreSQL database administrator (usually ``postgres``) to
 grant ``$USER`` the ability to create new databases. Next, you should
 as ``$USER`` run:
 
@@ -633,7 +633,7 @@ You can improve your security posture if you now REVOKE the 
rights to CREATE,
 DROP or ALTER tables from ``$USER``. However, if you do so, please be aware
 that you may have to temporarily GRANT those rights again when you update the
 merchant backend.  For details on how to REVOKE or GRANT these rights, consult
-the Postgres documentation.
+the PostgreSQL documentation.
 
 Commands, like ``taler-merchant-dbinit``, that support the ``-l LOGFILE``
 command-line option, send logging output to standard error by default.
@@ -782,7 +782,7 @@ The following is an example for a complete backend 
configuration:
    CURRENCY = KUDOS
 
 Given the above configuration, the backend will use a database named
-``donations`` within Postgres.
+``donations`` within PostgreSQL.
 
 The backend will deposit the coins it receives to the exchange at
 https://exchange.demo.taler.net/, which has the master key
@@ -1281,8 +1281,8 @@ merchant. Attempting to upgrade from or to a version in 
Git is not supported
 and may result in subtle data loss.
 
 To safely upgrade the merchant, you should first stop the existing
-``taler-merchant-httpd`` process, backup your merchant database (see Postgres
-manual), and then install the latest version of the code.
+``taler-merchant-httpd`` process, backup your merchant database (see
+PostgreSQL manual), and then install the latest version of the code.
 
 If you REVOKED database permissions, ensure that the rights to CREATE,
 DROP, and ALTER tables are GRANTed to ``$USER`` again.  Then, run:
@@ -1610,7 +1610,7 @@ A relatively minimal configuration could look like this:
 
 
 Note that the public key must match the exchange's
-private key and that the Postgres database must
+private key and that the PostgreSQL database must
 exist before launching the benchmark.  You also
 will need to ensure that the Exchange's
 details are set up.

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.