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
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>
<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>.
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>
<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
<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.
<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>
<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>
<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>
<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>
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>
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>
<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>
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.
<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',
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>
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
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
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.
<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.
<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.
<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>
<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"/>
<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>
<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>
<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>
</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>
<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>
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,
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',
projects / postgresql.git / commitdiff