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:
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -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.
|
||||
|
@ -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 > $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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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>
|
||||
|
@ -1256,7 +1256,7 @@ SELECT x, CASE WHEN x > 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,
|
||||
|
@ -304,7 +304,7 @@ AS t(article_id integer, author text, page_count integer, title text);
|
||||
just <literal>SELECT *</literal> — 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',
|
||||
|
Reference in New Issue
Block a user