1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00

doc: Properly punctuate "etc."

This commit is contained in:
Peter Eisentraut
2022-05-19 09:27:34 +02:00
parent c4a4e760f6
commit 648aa6734f
19 changed files with 32 additions and 32 deletions

View File

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

View File

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

View File

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

View File

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

View File

@ -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.

View File

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

View File

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

View File

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

View File

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

View File

@ -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.

View File

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

View File

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

View File

@ -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.

View File

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

View File

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

View File

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

View File

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

View File

@ -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,

View File

@ -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',