Replace PostgreSQL with &productname; (new instances)

dmpgpro · dmpgpro · commit 77055b62ed4f · 2016-10-05T17:59:55.000+03:00
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
@@ -933,7 +933,7 @@ SELECT * FROM pg_stop_backup(false);
      The process for an exclusive backup is mostly the same as for a
      non-exclusive one, but it differs in a few key steps. It does not allow
      more than one concurrent backup to run, and there can be some issues on
-     the server if it crashes during the backup. Prior to PostgreSQL 9.6, this
+     the server if it crashes during the backup. Prior to &productname; 9.6, this
      was the only low-level method available, but it is now recommended that
      all users upgrade their scripts to use non-exclusive backups if possible.
     </para>
diff --git a/doc/src/sgml/bgworker.sgml b/doc/src/sgml/bgworker.sgml
@@ -80,7 +80,7 @@ typedef struct BackgroundWorker
       <para>
        <indexterm><primary>BGWORKER_SHMEM_ACCESS</primary></indexterm>
        Requests shared memory access.  Workers without shared memory access
-       cannot access any of <productname>PostgreSQL's</productname> shared
+       cannot access any of <productname>&productname;'s</productname> shared
        data structures, such as heavyweight or lightweight locks, shared
        buffers, or any custom data structures which the worker itself may
        wish to create and use.
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
@@ -589,7 +589,7 @@
 
   <note>
    <para>
-    Before <productname>PostgreSQL</> 9.6, <structname>pg_am</structname>
+    Before <productname>&productname;</> 9.6, <structname>pg_am</structname>
     contained many additional columns representing properties of index access
     methods.  That data is now only directly visible at the C code level.
     However, <function>pg_index_column_has_property()</function> and related
@@ -7596,11 +7596,11 @@
   <para>
    The view <structname>pg_config</structname> describes the
    compile-time configuration parameters of the currently installed
-   version of <productname>PostgreSQL</>. It is intended, for example, to
+   version of <productname>&productname;</>. It is intended, for example, to
    be used by software packages that want to interface to
-   <productname>PostgreSQL</> to facilitate finding the required header
+   <productname>&productname;</> to facilitate finding the required header
    files and libraries. It provides the same basic information as the
-   <xref linkend="app-pgconfig"> <productname>PostgreSQL</> client
+   <xref linkend="app-pgconfig"> <productname>&productname;</> client
    application.
   </para>
 
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
@@ -1034,7 +1034,7 @@ omicron         bryanh                  guest1
         also used.  It is recommended to
         leave <literal>include_realm</literal> set to the default (1) and to
         provide an explicit mapping in <filename>pg_ident.conf</> to convert
-        principal names to <productname>PostgreSQL</> user names.
+        principal names to <productname>&productname;</> user names.
        </para>
       </listitem>
      </varlistentry>
@@ -1115,7 +1115,7 @@ omicron         bryanh                  guest1
         also used.  It is recommended to
         leave <literal>include_realm</literal> set to the default (1) and to
         provide an explicit mapping in <filename>pg_ident.conf</> to convert
-        principal names to <productname>PostgreSQL</> user names.
+        principal names to <productname>&productname;</> user names.
        </para>
       </listitem>
      </varlistentry>
@@ -1752,16 +1752,16 @@ host ... ldap ldapurl="ldap://ldap.example.net/dc=example,dc=net?uid?sub"
    </para>
 
    <para>
-    BSD Authentication in <productname>PostgreSQL</> uses
+    BSD Authentication in <productname>&productname;</> uses
     the <literal>auth-postgresql</literal> login type and authenticates with
     the <literal>postgresql</literal> login class if that's defined
     in <filename>login.conf</filename>. By default that login class does not
-    exist, and <productname>PostgreSQL</> will use the default login class.
+    exist, and <productname>&productname;</> will use the default login class.
    </para>
 
    <note>
     <para>
-     To use BSD Authentication, the PostgreSQL user account (that is, the
+     To use BSD Authentication, the &productname; user account (that is, the
      operating system user running the server) must first be added to
      the <literal>auth</literal> group.  The <literal>auth</literal> group
      exists by default on OpenBSD systems.
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
@@ -3056,7 +3056,7 @@ include_dir 'conf.d'
         <literal>s3</> and <literal>s4</>.
         </para>
         <para>
-        The second syntax was used before <productname>PostgreSQL</>
+        The second syntax was used before <productname>&productname;</>
         version 9.6 and is still supported. It's the same as the first syntax
         with <replaceable class="parameter">num_sync</replaceable> equal to 1.
         For example, <literal>1 (s1, s2)</> and
@@ -4519,7 +4519,7 @@ local0.*    /var/log/postgresql
         determines how messages are delivered to syslog.  When on (the
         default), messages are split by lines, and long lines are split so
         that they will fit into 1024 bytes, which is a typical size limit for
-        traditional syslog implementations.  When off, PostgreSQL server log
+        traditional syslog implementations.  When off, &productname; server log
         messages are delivered to the syslog service as is, and it is up to
         the syslog service to cope with the potentially bulky messages.
        </para>
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
@@ -354,7 +354,7 @@
    </para>
 
    <para>
-    <productname>PostgreSQL</> does not currently support extension scripts
+    <productname>&productname;</> does not currently support extension scripts
     issuing <command>CREATE POLICY</command> or <command>SECURITY LABEL</command>
     statements.  These are expected to be set after the extension has been
     created.  All RLS policies and security labels on extension objects will be
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
@@ -7750,7 +7750,7 @@ SELECT EXTRACT(YEAR FROM TIMESTAMP '2001-02-16 20:38:40');
      +/-Infinity for monotonically-increasing fields (<literal>epoch</>,
      <literal>julian</>, <literal>year</>, <literal>isoyear</>,
      <literal>decade</>, <literal>century</>, and <literal>millennium</>).
-     For other fields, NULL is returned.  <productname>PostgreSQL</>
+     For other fields, NULL is returned.  <productname>&productname;</>
      versions before 9.6 returned zero for all cases of infinite input.
     </para>
    </note>
diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml
@@ -1163,10 +1163,10 @@ CREATE INDEX test1c_content_y_index ON test1c (content COLLATE "y");
   </indexterm>
 
   <para>
-   All indexes in <productname>PostgreSQL</> are <firstterm>secondary</>
+   All indexes in <productname>&productname;</> are <firstterm>secondary</>
    indexes, meaning that each index is stored separately from the table's
    main data area (which is called the table's <firstterm>heap</>
-   in <productname>PostgreSQL</> terminology).  This means that in an
+   in <productname>&productname;</> terminology).  This means that in an
    ordinary index scan, each row retrieval requires fetching data from both
    the index and the heap.  Furthermore, while the index entries that match a
    given indexable <literal>WHERE</> condition are usually close together in
@@ -1179,7 +1179,7 @@ CREATE INDEX test1c_content_y_index ON test1c (content COLLATE "y");
   </para>
 
   <para>
-   To solve this performance problem, <productname>PostgreSQL</>
+   To solve this performance problem, <productname>&productname;</>
    supports <firstterm>index-only scans</>, which can answer queries from an
    index alone without any heap access.  The basic idea is to return values
    directly out of each index entry instead of consulting the associated heap
@@ -1226,14 +1226,14 @@ SELECT x FROM tab WHERE x = 'key' AND z &lt; 42;
    If these two fundamental requirements are met, then all the data values
    required by the query are available from the index, so an index-only scan
    is physically possible.  But there is an additional requirement for any
-   table scan in <productname>PostgreSQL</>: it must verify that each
+   table scan in <productname>&productname;</>: it must verify that each
    retrieved row be <quote>visible</> to the query's MVCC snapshot, as
    discussed in <xref linkend="mvcc">.  Visibility information is not stored
    in index entries, only in heap entries; so at first glance it would seem
    that every row retrieval would require a heap access anyway.  And this is
    indeed the case, if the table row has been modified recently.  However,
    for seldom-changing data there is a way around this
-   problem.  <productname>PostgreSQL</> tracks, for each page in a table's
+   problem.  <productname>&productname;</> tracks, for each page in a table's
    heap, whether all rows stored in that page are old enough to be visible to
    all current and future transactions.  This information is stored in a bit
    in the table's <firstterm>visibility map</>.  An index-only scan, after
@@ -1284,7 +1284,7 @@ SELECT y FROM tab WHERE x = 'key';
 SELECT f(x) FROM tab WHERE f(x) &lt; 1;
 </programlisting>
    as an index-only scan; and this is very attractive if <literal>f()</> is
-   an expensive-to-compute function.  However, <productname>PostgreSQL</>'s
+   an expensive-to-compute function.  However, <productname>&productname;</>'s
    planner is currently not very smart about such cases.  It considers a
    query to be potentially executable by index-only scan only when
    all <emphasis>columns</> needed by the query are available from the index.
@@ -1300,7 +1300,7 @@ SELECT f(x) FROM tab WHERE f(x) &lt; 1;
    indexable <literal>WHERE</> clauses to the index column.  It will usually
    get this right in simple queries such as shown above, but not in queries
    that involve joins.  These deficiencies may be remedied in future versions
-   of <productname>PostgreSQL</>.
+   of <productname>&productname;</>.
   </para>
 
   <para>
@@ -1321,7 +1321,7 @@ SELECT target FROM tests WHERE subject = 'some-subject' AND success;
    not need to recheck that part of the <literal>WHERE</> clause at run time:
    all entries found in the index necessarily have <literal>success = true</>
    so this need not be explicitly checked in the
-   plan.  <productname>PostgreSQL</> versions 9.6 and later will recognize
+   plan.  <productname>&productname;</> versions 9.6 and later will recognize
    such cases and allow index-only scans to be generated, but older versions
    will not.
   </para>
diff --git a/doc/src/sgml/intarray.sgml b/doc/src/sgml/intarray.sgml
@@ -307,7 +307,7 @@ SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
   <para>
    The source directory <filename>contrib/intarray/bench</> contains a
    benchmark test suite, which can be run against an installed
-   <productname>PostgreSQL</> server.  (It also requires <filename>DBD::Pg</>
+   <productname>&productname;</> server.  (It also requires <filename>DBD::Pg</>
    to be installed.)  To run:
   </para>
 
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
@@ -2777,7 +2777,7 @@ char *PQresultErrorField(const PGresult *res, int fieldcode);
             <literal>INFO</>, or <literal>LOG</> (in a notice message).
             This is identical to the <symbol>PG_DIAG_SEVERITY</> field except
             that the contents are never localized.  This is present only in
-            reports generated by <productname>PostgreSQL</> versions 9.6
+            reports generated by <productname>&productname;</> versions 9.6
             and later.
            </para>
           </listitem>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
@@ -2516,7 +2516,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
   <title>Progress Reporting</title>
 
   <para>
-   <productname>PostgreSQL</> has the ability to report the progress of
+   <productname>&productname;</> has the ability to report the progress of
    certain commands during command execution.  Currently, the only command
    which supports progress reporting is <command>VACUUM</>.  This may be
    expanded in the future.
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
@@ -701,7 +701,7 @@ ERROR:  could not serialize access due to read/write dependencies among transact
    </para>
 
    <para>
-    While <productname>PostgreSQL</>'s Serializable transaction isolation
+    While <productname>&productname;</>'s Serializable transaction isolation
     level only allows concurrent transactions to commit if it can prove there
     is a serial order of execution that would produce the same effect, it
     doesn't always prevent errors from being raised that would not occur in
diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
@@ -8,7 +8,7 @@
   </indexterm>
 
   <para>
-   <productname>PostgreSQL</> can devise query plans which can leverage
+   <productname>&productname;</> can devise query plans which can leverage
    multiple CPUs in order to answer queries faster.  This feature is known
    as parallel query.  Many queries cannot benefit from parallel query, either
    due to limitations of the current implementation or because there is no
@@ -295,7 +295,7 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
   </para>
 
   <para>
-    <productname>PostgreSQL</> supports parallel aggregation by aggregating
+    <productname>&productname;</> supports parallel aggregation by aggregating
     twice.  First, each process participating in the parallel portion of the
     query performs an aggregation step, producing a partial result for each
     group of which that process is aware.  This is reflected in the plan as
diff --git a/doc/src/sgml/pgquerystate.sgml b/doc/src/sgml/pgquerystate.sgml
@@ -57,7 +57,7 @@
       shared_preload_libraries = 'pg_query_state'
     </programlisting>
     <para>
-      It will require to restart the <productname>PostgreSQL</productname>
+      It will require to restart the <productname>&productname;</productname>
       instance.
     </para>
   </sect2>
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
@@ -4959,7 +4959,7 @@ CREATE FUNCTION
       <para>
        Data type names often need translation.  For example, in Oracle string
        values are commonly declared as being of type <type>varchar2</>, which
-       is a non-SQL-standard type.  In <productname>PostgreSQL</productname>,
+       is a non-SQL-standard type.  In <productname>&productname;</productname>,
        use type <type>varchar</> or <type>text</> instead.  Similarly, replace
        type <type>number</> with <type>numeric</>, or use some other numeric
        data type if there's a more appropriate one.
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
@@ -284,7 +284,7 @@
      <listitem>
       <para>
        This option is a comma-separated list of names
-       of <productname>PostgreSQL</> extensions that are installed, in
+       of <productname>&productname;</> extensions that are installed, in
        compatible versions, on both the local and remote servers.  Functions
        and operators that are immutable and belong to a listed extension will
        be considered shippable to the remote server.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
@@ -4895,7 +4895,7 @@ message.
         <literal>INFO</>, or <literal>LOG</> (in a notice message).
         This is identical to the <literal>S</> field except
         that the contents are never localized.  This is present only in
-        messages generated by <productname>PostgreSQL</> versions 9.6
+        messages generated by <productname>&productname;</> versions 9.6
         and later.
 </para>
 </listitem>
diff --git a/doc/src/sgml/ref/create_access_method.sgml b/doc/src/sgml/ref/create_access_method.sgml
@@ -1,6 +1,6 @@
 <!--
 doc/src/sgml/ref/create_access_method.sgml
-PostgreSQL documentation
+&productname; documentation
 -->
 
 <refentry id="sql-create-access-method">
@@ -102,7 +102,7 @@ CREATE ACCESS METHOD heptree TYPE INDEX HANDLER heptree_handler;
 
   <para>
    <command>CREATE ACCESS METHOD</command> is a
-   <productname>PostgreSQL</> extension.
+   <productname>&productname;</> extension.
   </para>
  </refsect1>
 
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
@@ -151,7 +151,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] <replaceable class=
         from <firstterm>index-only scans</> by including certain columns in the
         index, the value of which would otherwise have to be obtained by reading
         the table's heap. Having these columns in the <literal>INCLUDING</> clause
-        in some cases allows <productname>PostgreSQL</> to skip the heap read
+        in some cases allows <productname>&productname;</> to skip the heap read
         completely. This also allows <literal>UNIQUE</> indexes to be defined on
         one set of columns, which can include another set of column in the
         <literal>INCLUDING</> clause, on which the uniqueness is not enforced upon.
diff --git a/doc/src/sgml/ref/drop_access_method.sgml b/doc/src/sgml/ref/drop_access_method.sgml
@@ -1,6 +1,6 @@
 <!--
 doc/src/sgml/ref/drop_access_method.sgml
-PostgreSQL documentation
+&productname; documentation
 -->
 
 <refentry id="sql-drop-access-method">
@@ -96,7 +96,7 @@ DROP ACCESS METHOD heptree;
 
   <para>
    <command>DROP ACCESS METHOD</command> is a
-   <productname>PostgreSQL</> extension.
+   <productname>&productname;</> extension.
   </para>
  </refsect1>
 
diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml
@@ -424,7 +424,7 @@
 
        <note>
         <para>
-         In versions prior to <productname>PostgreSQL</> 9.6, this flag
+         In versions prior to <productname>&productname;</> 9.6, this flag
          matched only tables, not any other type of relation.
         </para>
        </note>
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
@@ -753,7 +753,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
 
   <note>
    <para>
-    Before <productname>PostgreSQL</> 9.6, SQL commands in script files
+    Before <productname>&productname;</> 9.6, SQL commands in script files
     were terminated by newlines, and so they could not be continued across
     lines.  Now a semicolon is <emphasis>required</> to separate consecutive
     SQL commands (though a SQL command does not need one if it is followed
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
@@ -4010,7 +4010,7 @@ PSQL_EDITOR_LINENUMBER_ARG='--line '
 
       <listitem>
       <para>
-       Before <productname>PostgreSQL</productname> 9.6,
+       Before <productname>&productname;</productname> 9.6,
        the <option>-c</option> option implied <option>-X</option>
        (<option>--no-psqlrc</>); this is no longer the case.
       </para>
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
@@ -1005,7 +1005,7 @@ UNBOUNDED FOLLOWING
     contains any volatile or expensive functions.  With that behavior, the
     order of function evaluations is more intuitive and there will not be
     evaluations corresponding to rows that never appear in the output.
-    <productname>PostgreSQL</> will effectively evaluate output expressions
+    <productname>&productname;</> will effectively evaluate output expressions
     after sorting and limiting, so long as those expressions are not
     referenced in <literal>DISTINCT</literal>, <literal>ORDER BY</literal>
     or <literal>GROUP BY</literal>.  (As a counterexample, <literal>SELECT
@@ -1018,7 +1018,7 @@ UNBOUNDED FOLLOWING
 
    <note>
     <para>
-     <productname>PostgreSQL</> versions before 9.6 did not provide any
+     <productname>&productname;</> versions before 9.6 did not provide any
      guarantees about the timing of evaluation of output expressions versus
      sorting and limiting; it depended on the form of the chosen query plan.
     </para>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
@@ -385,7 +385,7 @@ fi
       at <filename>/etc/systemd/system/postgresql.service</filename>):<indexterm><primary>systemd</primary></indexterm>
 <programlisting>
 [Unit]
-Description=PostgreSQL database server
+Description=&productname; database server
 Documentation=man:postgres(1)
 
 [Service]
@@ -408,7 +408,7 @@ WantedBy=multi-user.target
       Consider carefully the timeout
       setting.  <application>systemd</application> has a default timeout of 90
       seconds as of this writing and will kill a process that does not notify
-      readiness within that time.  But a <productname>PostgreSQL</productname>
+      readiness within that time.  But a <productname>&productname;</productname>
       server that might have to perform crash recovery at startup could take
       much longer to become ready.  The suggested value of 0 disables the
       timeout logic.
@@ -2172,7 +2172,7 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
    owned by root and have group read access (that is, <literal>0640</literal>
    permissions).  That setup is intended for installations where certificate
    and key files are managed by the operating system.  The user under which
-   the <productname>PostgreSQL</productname> server runs should then be made a
+   the <productname>&productname;</productname> server runs should then be made a
    member of the group that has access to those certificate and key files.
   </para>
 
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
