summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--doc/src/sgml/arch-dev.sgml2
-rw-r--r--doc/src/sgml/bki.sgml4
-rw-r--r--doc/src/sgml/config.sgml4
-rw-r--r--doc/src/sgml/datetime.sgml2
-rw-r--r--doc/src/sgml/ddl.sgml2
-rw-r--r--doc/src/sgml/extend.sgml2
-rw-r--r--doc/src/sgml/func.sgml2
-rw-r--r--doc/src/sgml/glossary.sgml2
-rw-r--r--doc/src/sgml/libpq.sgml8
-rw-r--r--doc/src/sgml/manage-ag.sgml2
-rw-r--r--doc/src/sgml/plperl.sgml6
-rw-r--r--doc/src/sgml/pltcl.sgml2
-rw-r--r--doc/src/sgml/postgres-fdw.sgml2
-rw-r--r--doc/src/sgml/protocol.sgml12
-rw-r--r--doc/src/sgml/ref/values.sgml2
-rw-r--r--doc/src/sgml/sources.sgml4
-rw-r--r--doc/src/sgml/syntax.sgml2
-rw-r--r--doc/src/sgml/xfunc.sgml2
-rw-r--r--doc/src/sgml/xml2.sgml2
19 files changed, 32 insertions, 32 deletions
diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index c2be28fac89..1315ce962df 100644
--- 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
index 20894baf185..f71644e3989 100644
--- 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
index 03986946a83..8cefe7045b6 100644
--- 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
index adaf72dcbd5..ecc3245a469 100644
--- 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
index f2ac1ba0034..b01e3ad5445 100644
--- 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
index e928894726c..b3857015b17 100644
--- 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
index 85ecc639fda..8819b60685f 100644
--- 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
index f81fdc31f9e..d6d0a3a8140 100644
--- 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
index 1c20901c3c1..40035d76564 100644
--- 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
index 23f116befeb..8903ab2fc9c 100644
--- 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
index 627c7936fc9..6c81ee8fbe1 100644
--- 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
index 9839e375ad3..bf56ba6b1c6 100644
--- 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
index 68362fd1604..bfd344cdc0e 100644
--- 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
index a155370a3c4..bb303408929 100644
--- 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
index d3a3aaff140..4bf7bfdffee 100644
--- 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
index 2d01efc950c..5186d75d616 100644
--- 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
index 487ea58d895..a99c24373e4 100644
--- 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
index 3b0adc0704b..b8cefb9c2ca 100644
--- 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
index 584bb3e923f..47650d9dfd7 100644
--- 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',
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-17 04:30:49 +0000