doc: Properly punctuate "etc."

petere · petere · commit 648aa6734fef · 2022-05-19T09:42:17.000+02:00
diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
@@ -261,7 +261,7 @@
      system catalog lookups can only be done within a transaction, and we
      do not wish to start a transaction immediately upon receiving a query
      string.  The raw parsing stage is sufficient to identify the transaction
-     control commands (<command>BEGIN</command>, <command>ROLLBACK</command>, etc), and
+     control commands (<command>BEGIN</command>, <command>ROLLBACK</command>, etc.), and
      these can then be correctly executed without any further analysis.
      Once we know that we are dealing with an actual query (such as
      <command>SELECT</command> or <command>UPDATE</command>), it is okay to
diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml
@@ -836,11 +836,11 @@ $ perl  rewrite_dat_with_prokind.pl  pg_proc.dat
       When <literal>bootstrap</literal> is specified,
       the table will only be created on disk; nothing is entered into
       <structname>pg_class</structname>,
-      <structname>pg_attribute</structname>, etc, for it.  Thus the
+      <structname>pg_attribute</structname>, etc., for it.  Thus the
       table will not be accessible by ordinary SQL operations until
       such entries are made the hard way (with <literal>insert</literal>
       commands).  This option is used for creating
-      <structname>pg_class</structname> etc themselves.
+      <structname>pg_class</structname> etc. themselves.
      </para>
 
      <para>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
@@ -6374,7 +6374,7 @@ local0.*    /var/log/postgresql
        <para>
         Example:  To keep 7 days of logs, one log file per day named
         <literal>server_log.Mon</literal>, <literal>server_log.Tue</literal>,
-        etc, and automatically overwrite last week's log with this week's log,
+        etc., and automatically overwrite last week's log with this week's log,
         set <varname>log_filename</varname> to <literal>server_log.%a</literal>,
         <varname>log_truncate_on_rotation</varname> to <literal>on</literal>, and
         <varname>log_rotation_age</varname> to <literal>1440</literal>.
@@ -8552,7 +8552,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
         alias <literal>pg_temp</literal><indexterm><primary>pg_temp</primary></indexterm>.  If it is not listed in the path then
         it is searched first (even before <literal>pg_catalog</literal>).  However,
         the temporary schema is only searched for relation (table, view,
-        sequence, etc) and data type names.  It is never searched for
+        sequence, etc.) and data type names.  It is never searched for
         function or operator names.
        </para>
 
diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml
@@ -515,7 +515,7 @@
 
    <para>
     For reference purposes, a standard installation also contains files
-    <filename>Africa.txt</filename>, <filename>America.txt</filename>, etc, containing
+    <filename>Africa.txt</filename>, <filename>America.txt</filename>, etc., containing
     information about every time zone abbreviation known to be in use
     according to the IANA timezone database.  The zone name
     definitions found in these files can be copied and pasted into a custom
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
@@ -1694,7 +1694,7 @@ ALTER TABLE products RENAME TO items;
    <literal>EXECUTE</literal>, <literal>USAGE</literal>, <literal>SET</literal>
    and <literal>ALTER SYSTEM</literal>.
    The privileges applicable to a particular
-   object vary depending on the object's type (table, function, etc).
+   object vary depending on the object's type (table, function, etc.).
    More detail about the meanings of these privileges appears below.
    The following sections and chapters will also show you how
    these privileges are used.
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
@@ -825,7 +825,7 @@ RETURNS anycompatible AS ...
     <para>
      An extension's <acronym>SQL</acronym> script files can contain any SQL commands,
      except for transaction control commands (<command>BEGIN</command>,
-     <command>COMMIT</command>, etc) and commands that cannot be executed inside a
+     <command>COMMIT</command>, etc.) and commands that cannot be executed inside a
      transaction block (such as <command>VACUUM</command>).  This is because the
      script files are implicitly executed within a transaction block.
     </para>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
@@ -6156,7 +6156,7 @@ regexp_substr('ABCDEFGHI', '(c..)(...)', 1, 1, 'i', 2)
    <para>
     A branch is zero or more <firstterm>quantified atoms</firstterm> or
     <firstterm>constraints</firstterm>, concatenated.
-    It matches a match for the first, followed by a match for the second, etc;
+    It matches a match for the first, followed by a match for the second, etc.;
     an empty branch matches the empty string.
    </para>
 
diff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
@@ -1389,7 +1389,7 @@
     <para>
      More generically, the term <firstterm>schema</firstterm> is used to mean
      all data descriptions (<glossterm linkend="glossary-table">table</glossterm> definitions,
-     <glossterm linkend="glossary-constraint">constraints</glossterm>, comments, etc)
+     <glossterm linkend="glossary-constraint">constraints</glossterm>, comments, etc.)
      for a given <glossterm linkend="glossary-database">database</glossterm> or
      subset thereof.
     </para>
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
@@ -3049,7 +3049,7 @@ PGresult *PQdescribePrepared(PGconn *conn, const char *stmtName);
         <structname>PGresult</structname> to obtain information about the parameters
         of the prepared statement, and the functions
         <xref linkend="libpq-PQnfields"/>, <xref linkend="libpq-PQfname"/>,
-        <xref linkend="libpq-PQftype"/>, etc provide information about the
+        <xref linkend="libpq-PQftype"/>, etc. provide information about the
         result columns (if any) of the statement.
        </para>
       </listitem>
@@ -3081,7 +3081,7 @@ PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
         portal.  On success, a <structname>PGresult</structname> with status
         <literal>PGRES_COMMAND_OK</literal> is returned.  The functions
         <xref linkend="libpq-PQnfields"/>, <xref linkend="libpq-PQfname"/>,
-        <xref linkend="libpq-PQftype"/>, etc can be applied to the
+        <xref linkend="libpq-PQftype"/>, etc. can be applied to the
         <structname>PGresult</structname> to obtain information about the result
         columns (if any) of the portal.
        </para>
@@ -5544,7 +5544,7 @@ UPDATE mytable SET x = x + 1 WHERE id = 42;
    more rows will arrive.  (But note that it is still necessary to continue
    calling <xref linkend="libpq-PQgetResult"/> until it returns null.)  All of
    these <structname>PGresult</structname> objects will contain the same row
-   description data (column names, types, etc) that an ordinary
+   description data (column names, types, etc.) that an ordinary
    <structname>PGresult</structname> object for the query would have.
    Each object should be freed with <xref linkend="libpq-PQclear"/> as usual.
   </para>
@@ -6010,7 +6010,7 @@ typedef struct pgNotify
      <listitem>
       <para>
        0 indicates the overall copy format is textual (rows separated by
-       newlines, columns separated by separator characters, etc).  1
+       newlines, columns separated by separator characters, etc.).  1
        indicates the overall copy format is binary.  See <xref
        linkend="sql-copy"/> for more information.
       </para>
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
@@ -412,7 +412,7 @@ dropdb <replaceable class="parameter">dbname</replaceable>
      of data files. They are dependent on metadata contained in the main
      data directory, and therefore cannot be attached to a different
      database cluster or backed up individually.  Similarly, if you lose
-     a tablespace (file deletion, disk failure, etc), the database cluster
+     a tablespace (file deletion, disk failure, etc.), the database cluster
      might become unreadable or unable to start.  Placing a tablespace
      on a temporary file system like a RAM disk risks the reliability of
      the entire cluster.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
@@ -632,7 +632,7 @@ SELECT * from lotsa_md5(500);
     <para>
     <literal>spi_prepare</literal>, <literal>spi_query_prepared</literal>, <literal>spi_exec_prepared</literal>,
     and <literal>spi_freeplan</literal> implement the same functionality but for prepared queries.
-    <literal>spi_prepare</literal> accepts a query string with numbered argument placeholders ($1, $2, etc)
+    <literal>spi_prepare</literal> accepts a query string with numbered argument placeholders ($1, $2, etc.)
     and a string list of argument types:
 <programlisting>
 $plan = spi_prepare('SELECT * FROM test WHERE id &gt; $1 AND name = $2',
@@ -677,7 +677,7 @@ SELECT done();
  2005-12-10 | 2005-12-11 | 2005-12-12
 </programlisting>
     Note that the parameter subscript in <literal>spi_prepare</literal> is defined via
-    $1, $2, $3, etc, so avoid declaring query strings in double quotes that might easily
+    $1, $2, $3, etc., so avoid declaring query strings in double quotes that might easily
     lead to hard-to-catch bugs.
     </para>
 
@@ -1051,7 +1051,7 @@ $$ LANGUAGE plperl;
    PL/Perl functions will share the same value of <varname>%_SHARED</varname>
    if and only if they are executed by the same SQL role.  In an application
    wherein a single session executes code under multiple SQL roles (via
-   <literal>SECURITY DEFINER</literal> functions, use of <command>SET ROLE</command>, etc)
+   <literal>SECURITY DEFINER</literal> functions, use of <command>SET ROLE</command>, etc.)
    you may need to take explicit steps to ensure that PL/Perl functions can
    share data via <varname>%_SHARED</varname>.  To do that, make sure that
    functions that should communicate are owned by the same user, and mark
diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml
@@ -279,7 +279,7 @@ $$ LANGUAGE pltcl;
      functions will share the same global variables if and only if they are
      executed by the same SQL role.  In an application wherein a single
      session executes code under multiple SQL roles (via <literal>SECURITY
-     DEFINER</literal> functions, use of <command>SET ROLE</command>, etc) you may need to
+     DEFINER</literal> functions, use of <command>SET ROLE</command>, etc.) you may need to
      take explicit steps to ensure that PL/Tcl functions can share data.  To
      do that, make sure that functions that should communicate are owned by
      the same user, and mark them <literal>SECURITY DEFINER</literal>.  You must of
diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
@@ -190,7 +190,7 @@ OPTIONS (ADD password_required 'false');
     on the <literal>public</literal> role. Keep in mind that the mapped
     user can potentially use any client certificates,
     <filename>.pgpass</filename>,
-    <filename>.pg_service.conf</filename> etc in the unix home directory of the
+    <filename>.pg_service.conf</filename> etc. in the unix home directory of the
     system user the postgres server runs as. They can also use any trust
     relationship granted by authentication modes like <literal>peer</literal>
     or <literal>ident</literal> authentication.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
@@ -148,7 +148,7 @@
     <firstterm>bind</firstterm> step, which creates a portal given a prepared
     statement and values for any needed parameters; and an
     <firstterm>execute</firstterm> step that runs a portal's query.  In the case of
-    a query that returns rows (<command>SELECT</command>, <command>SHOW</command>, etc),
+    a query that returns rows (<command>SELECT</command>, <command>SHOW</command>, etc.),
     the execute step can be told to fetch only
     a limited number of rows, so that multiple execute steps might be needed
     to complete the operation.
@@ -584,7 +584,7 @@
       <listitem>
        <para>
         Indicates that rows are about to be returned in response to
-        a <command>SELECT</command>, <command>FETCH</command>, etc query.
+        a <command>SELECT</command>, <command>FETCH</command>, etc. query.
         The contents of this message describe the column layout of the rows.
         This will be followed by a DataRow message for each row being returned
         to the frontend.
@@ -597,7 +597,7 @@
       <listitem>
        <para>
         One of the set of rows returned by
-        a <command>SELECT</command>, <command>FETCH</command>, etc query.
+        a <command>SELECT</command>, <command>FETCH</command>, etc. query.
        </para>
       </listitem>
      </varlistentry>
@@ -4203,7 +4203,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
         <para>
          0 indicates the overall <command>COPY</command> format is textual (rows
          separated by newlines, columns separated by separator
-         characters, etc).
+         characters, etc.).
          1 indicates the overall copy format is binary (similar
          to DataRow format).
          See <xref linkend="sql-copy"/>
@@ -4265,7 +4265,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
         <para>
          0 indicates the overall <command>COPY</command> format
          is textual (rows separated by newlines, columns
-         separated by separator characters, etc). 1 indicates
+         separated by separator characters, etc.). 1 indicates
          the overall copy format is binary (similar to DataRow
          format). See <xref linkend="sql-copy"/> for more information.
         </para>
@@ -4325,7 +4325,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
         <para>
          0 indicates the overall <command>COPY</command> format
          is textual (rows separated by newlines, columns
-         separated by separator characters, etc). 1 indicates
+         separated by separator characters, etc.). 1 indicates
          the overall copy format is binary (similar to DataRow
          format). See <xref linkend="sql-copy"/> for more information.
         </para>
diff --git a/doc/src/sgml/ref/values.sgml b/doc/src/sgml/ref/values.sgml
@@ -203,7 +203,7 @@ UPDATE employees SET salary = salary * v.increase
    <command>SELECT</command>.  It is not required that the <literal>AS</literal> clause
    specify names for all the columns, but it's good practice to do so.
    (The default column names for <command>VALUES</command> are <literal>column1</literal>,
-   <literal>column2</literal>, etc in <productname>PostgreSQL</productname>, but
+   <literal>column2</literal>, etc. in <productname>PostgreSQL</productname>, but
    these names might be different in other database systems.)
   </para>
 
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
@@ -13,9 +13,9 @@
    </para>
 
    <para>
-    Layout rules (brace positioning, etc) follow BSD conventions.  In
+    Layout rules (brace positioning, etc.) follow BSD conventions.  In
     particular, curly braces for the controlled blocks of <literal>if</literal>,
-    <literal>while</literal>, <literal>switch</literal>, etc go on their own lines.
+    <literal>while</literal>, <literal>switch</literal>, etc. go on their own lines.
    </para>
 
    <para>
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
@@ -1062,7 +1062,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
        <entry><token>IS</token> <token>ISNULL</token> <token>NOTNULL</token></entry>
        <entry></entry>
        <entry><literal>IS TRUE</literal>, <literal>IS FALSE</literal>, <literal>IS
-       NULL</literal>, <literal>IS DISTINCT FROM</literal>, etc</entry>
+       NULL</literal>, <literal>IS DISTINCT FROM</literal>, etc.</entry>
       </row>
 
       <row>
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
@@ -1256,7 +1256,7 @@ SELECT x, CASE WHEN x &gt; 0 THEN generate_series(1, 5) ELSE 0 END FROM tab;
       described above; instead, a set-returning function could have at most
       one set-returning argument, and each nest of set-returning functions
       was run independently.  Also, conditional execution (set-returning
-      functions inside <literal>CASE</literal> etc) was previously allowed,
+      functions inside <literal>CASE</literal> etc.) was previously allowed,
       complicating things even more.
       Use of the <literal>LATERAL</literal> syntax is recommended when writing
       queries that need to work in older <productname>PostgreSQL</productname> versions,
diff --git a/doc/src/sgml/xml2.sgml b/doc/src/sgml/xml2.sgml
@@ -304,7 +304,7 @@ AS t(article_id integer, author text, page_count integer, title text);
    just <literal>SELECT *</literal> &mdash; it can reference the output
    columns by name or join them to other tables. The function produces a
    virtual table with which you can perform any operation you wish (e.g.,
-   aggregation, joining, sorting etc). So we could also have:
+   aggregation, joining, sorting etc.). So we could also have:
 <programlisting>
 SELECT t.title, p.fullname, p.email
 FROM xpath_table('article_id', 'article_xml', 'articles',
