between Postgres and PostgreSQL.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ABORT">
SQL92
</title>
<para>
- This command is a <productname>Postgres</productname> extension present
+ This command is a <productname>PostgreSQL</productname> extension present
for historical reasons. <command>ROLLBACK</command> is the <acronym>SQL92</acronym>
equivalent command.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
Complete list of usable sgml source files in this directory.
-->
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ALTERGROUP">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ALTERTABLE">
<para>
SQL92 specifies some additional capabilities for <command>ALTER TABLE</command>
- statement which are not yet directly supported by <productname>Postgres</productname>:
+ statement which are not yet directly supported by <productname>PostgreSQL</productname>:
<variablelist>
<varlistentry>
<para>
The clauses to rename tables, columns, indexes, and sequences are
- <productname>Postgres</productname> extensions from SQL92.
+ <productname>PostgreSQL</productname> extensions from SQL92.
</para>
</refsect2>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ALTERUSER">
</title>
<para>
<command>ALTER USER</command> is used to change the attributes of a user's
- <productname>Postgres</productname> account. Attributes not mentioned
+ <productname>PostgreSQL</productname> account. Attributes not mentioned
in the command retain their previous settings.
</para>
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ANALYZE">
</title>
<para>
<command>ANALYZE</command> collects statistics about the contents of
- <productname>Postgres</productname> tables, and stores the results in
+ <productname>PostgreSQL</productname> tables, and stores the results in
the system table <literal>pg_statistic</literal>. Subsequently,
the query planner uses the statistics to help determine the most efficient
execution plans for queries.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-BEGIN">
</title>
<para>
- By default, <productname>Postgres</productname> executes transactions
+ By default, <productname>PostgreSQL</productname> executes transactions
in <firstterm>unchained mode</firstterm>
(also known as <quote>autocommit</quote> in other database
systems).
<para>
The default transaction isolation level in
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
is READ COMMITTED, where queries inside the transaction see only changes
committed before query execution. So, you have to use
<command>SET TRANSACTION ISOLATION LEVEL SERIALIZABLE</command>
</para>
<para>
- If the transaction is committed, <productname>Postgres</productname>
+ If the transaction is committed, <productname>PostgreSQL</productname>
will ensure either that all updates are done or else that none of
them are done. Transactions have the standard <acronym>ACID</acronym>
(atomic, consistent, isolatable, and durable) property.
<para>
<command>BEGIN</command>
- is a <productname>Postgres</productname> language extension.
+ is a <productname>PostgreSQL</productname> language extension.
There is no explicit <command>BEGIN</command>
command in <acronym>SQL92</acronym>;
transaction initiation is always implicit and it terminates either
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CLOSE">
Notes
</title>
<para>
- <productname>Postgres</productname> does not have
+ <productname>PostgreSQL</productname> does not have
an explicit <command>OPEN</command> cursor statement;
a cursor is considered open when it is declared.
Use the <command>DECLARE</command> statement to declare a cursor.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CLUSTER">
Description
</title>
<para>
- <command>CLUSTER</command> instructs <productname>Postgres</productname>
+ <command>CLUSTER</command> instructs <productname>PostgreSQL</productname>
to cluster the table specified
by <replaceable class="parameter">table</replaceable> approximately
based on the index specified by
on large tables because the rows are fetched from the heap
in index order, and if the heap table is unordered, the
entries are on random pages, so there is one disk page
- retrieved for every row moved. <productname>Postgres</productname> has a cache,
+ retrieved for every row moved. <productname>PostgreSQL</productname> has a cache,
but the majority of a big table will not fit in the cache.
</para>
FROM <replaceable class="parameter">table</replaceable> ORDER BY <replaceable class="parameter">columnlist</replaceable>
</programlisting>
- which uses the <productname>Postgres</productname> sorting code in
+ which uses the <productname>PostgreSQL</productname> sorting code in
the ORDER BY clause to match the index, and which is much faster for
unordered data. You then drop the old table, use
<command>ALTER TABLE...RENAME</command>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-COMMENT">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-COMMIT">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-COPY">
</title>
<para>
<command>COPY</command> moves data between
- <productname>Postgres</productname> tables and
+ <productname>PostgreSQL</productname> tables and
standard file-system files.
<command>COPY TO</command> copies the entire contents of a table to
<para>
<command>COPY</command> with a filename instructs
- the <productname>Postgres</productname> backend
+ the <productname>PostgreSQL</productname> backend
to directly read from or write to a file.
The file must be accessible to the backend and the name must be specified
from the viewpoint of the backend.
directly by the backend, not by the client application. Therefore,
they must reside on or be accessible to the database server machine,
not the client. They must be accessible to and readable or writable
- by the Postgres user (the userid the backend runs as), not the client.
+ by the <application>PostgreSQL</application> user (the userid the
+ backend runs as), not the client.
<command>COPY</command> naming a file is only allowed to database
superusers, since it allows writing on any file that the backend has
privileges to write on.
as the column delimiter, backslash that delimiter character to include
it in data.) A literal newline character is
represented as a backslash and a newline. When loading text data
- not generated by <acronym>Postgres</acronym>,
+ not generated by <application>PostgreSQL</application>,
you will need to convert backslash
characters ("\") to double-backslashes ("\\") to ensure that they
are loaded properly.
<title>Binary Format</title>
<para>
The file format used for <command>COPY BINARY</command> changed in
- Postgres v7.1. The new format consists of a file header, zero or more
+ <application>PostgreSQL</application> v7.1.
+ The new format consists of a file header, zero or more
tuples, and a file trailer.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEAGGREGATE">
</title>
<para>
<command>CREATE AGGREGATE</command>
- allows a user or programmer to extend <productname>Postgres</productname>
+ allows a user or programmer to extend <productname>PostgreSQL</productname>
functionality by defining new aggregate functions. Some aggregate functions
for base types such as <function>min(integer)</function>
and <function>avg(double precision)</function> are already provided in the base
</programlisting>
</para>
<para>
- <productname>Postgres</productname> creates a temporary variable
+ <productname>PostgreSQL</productname> creates a temporary variable
of data type <replaceable class="PARAMETER">stype</replaceable>
to hold the current internal state of the aggregate. At each input
data item,
</title>
<para>
<command>CREATE AGGREGATE</command>
- is a <productname>Postgres</productname> language extension.
+ is a <productname>PostgreSQL</productname> language extension.
There is no <command>CREATE AGGREGATE</command> in SQL92.
</para>
</refsect2>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATECONSTRAINT">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEDATABASE">
</title>
<para>
<command>CREATE DATABASE</command> creates a new
- <productname>Postgres</productname> database.
+ <productname>PostgreSQL</productname> database.
The creator becomes the owner of the new database.
</para>
<replaceable class="parameter">name</replaceable>. In particular,
by writing <literal>TEMPLATE = template0</>, you can create a virgin
database containing only the standard objects predefined by your
- version of Postgres. This is useful if you wish to avoid copying
+ version of <application>PostgreSQL</application>. This is useful
+ if you wish to avoid copying
any installation-local objects that may have been added to
<literal>template1</>.
</para>
Notes
</title>
<para>
- <command>CREATE DATABASE</command> is a <productname>Postgres</productname>
+ <command>CREATE DATABASE</command> is a <productname>PostgreSQL</productname>
language extension.
</para>
<para>
comment from Olly; response from Thomas...
<comment>
initlocation does not create a PG_VERSION file in the specified location.
- How will Postgres handle the situation if it is upgraded to an
+ How will PostgreSQL handle the situation if it is upgraded to an
incompatible database version?
</comment>
Hmm. This isn't an issue since the upgrade would do
<programlisting>
<prompt>$</prompt> <userinput>mkdir private_db</userinput>
<prompt>$</prompt> <userinput>initlocation ~/private_db</userinput>
-<computeroutput>Creating Postgres database system directory /home/olly/private_db/base</computeroutput>
+ <computeroutput>
+The location will be initialized with username "olly".
+This user will own all the files and must also own the server process.
+Creating directory /home/olly/private_db
+Creating directory /home/olly/private_db/base
+
+initlocation is complete.
+ </computeroutput>
<prompt>$</prompt> <userinput>psql olly</userinput>
<computeroutput>
Refer to the chapter in the
<citetitle>PostgreSQL Programmer's Guide</citetitle>
on the topic of extending
- <productname>Postgres</productname> via functions
+ <productname>PostgreSQL</productname> via functions
for further information on writing external functions.
</para>
</para>
<para>
- <productname>Postgres</productname> allows function <firstterm>overloading</firstterm>;
+ <productname>PostgreSQL</productname> allows function <firstterm>overloading</firstterm>;
that is, the same name can be used for several different functions
so long as they have distinct argument types. This facility must
be used with caution for internal and C-language functions, however.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEGROUP">
<listitem>
<para>
The <literal>SYSID</literal> clause can be used to choose
- the <productname>Postgres</productname> group id of the new
+ the <productname>PostgreSQL</productname> group id of the new
group. It is not necessary to do so, however.
</para>
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEINDEX">
<para>
The name of the access method to be used for
the index. The default access method is BTREE.
- Postgres provides four access methods for indexes:
+ <application>PostgreSQL</application> provides four access methods for indexes:
<variablelist>
<varlistentry>
</para>
<para>
- Postgres provides btree, rtree, hash, and GiST access methods for
+ <application>PostgreSQL</application> provides btree, rtree, hash, and GiST access methods for
indexes. The btree access method is an implementation of
Lehman-Yao high-concurrency btrees. The rtree access method
implements standard rtrees using Guttman's quadratic split algorithm.
</title>
<para>
- The <productname>Postgres</productname>
+ The <productname>PostgreSQL</productname>
query optimizer will consider using a btree index whenever
an indexed attribute is involved in a comparison using one of:
</para>
<para>
- The <productname>Postgres</productname>
+ The <productname>PostgreSQL</productname>
query optimizer will consider using an rtree index whenever
an indexed attribute is involved in a comparison using one of:
</para>
<para>
- The <productname>Postgres</productname>
+ The <productname>PostgreSQL</productname>
query optimizer will consider using a hash index whenever
an indexed attribute is involved in a comparison using
the <literal>=</literal> operator.
<para>
Currently, only the btree and gist access methods support multi-column
indexes. Up to 16 keys may be specified by default (this limit
- can be altered when building Postgres). Only btree currently supports
+ can be altered when building
+ <application>PostgreSQL</application>). Only btree currently supports
unique indexes.
</para>
SQL92
</title>
<para>
- CREATE INDEX is a <productname>Postgres</productname> language extension.
+ CREATE INDEX is a <productname>PostgreSQL</productname> language extension.
</para>
<para>
There is no <command>CREATE INDEX</command> command in SQL92.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATELANGUAGE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEOPERATOR">
</literallayout>
For example, <literal>@-</literal> is an allowed operator name,
but <literal>*-</literal> is not.
- This restriction allows <productname>Postgres</productname> to
+ This restriction allows <productname>PostgreSQL</productname> to
parse SQL-compliant queries without requiring spaces between tokens.
</para>
</listitem>
For example, if you have defined a left-unary operator named <literal>@</literal>,
you cannot write <literal>X*@Y</literal>; you must write
<literal>X* @Y</literal> to ensure that
- <productname>Postgres</productname> reads it as two operator names
+ <productname>PostgreSQL</productname> reads it as two operator names
not one.
</para>
</note>
</para>
<para>
The commutator operator should be identified if one exists,
- so that <productname>Postgres</productname> can
+ so that <productname>PostgreSQL</productname> can
reverse the order of the operands if it wishes.
For example, the operator area-less-than, <<<,
would probably have a commutator
</para>
<para>
If a commutator operator name is supplied,
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
searches for it in the catalog. If it is found and it
does not yet have a commutator itself, then the commutator's
entry is updated to have the newly created operator as its
operator should be defined without a commutator or negator
(as appropriate). When the second operator is defined,
name the first as the commutator or negator. The first
- will be updated as a side effect. (As of Postgres 6.5,
+ will be updated as a side effect. (As of
+ <application>PostgreSQL</application> <literal>6.5</literal>,
it also works to just have both operators refer to each other.)
</para>
<para>
The HASHES, SORT1, and SORT2 options are present to support the
query optimizer in performing joins.
- <productname>Postgres</productname> can always
+ <productname>PostgreSQL</productname> can always
evaluate a join (i.e., processing a clause with two tuple
variables separated by an operator that returns a boolean)
by iterative substitution [WONG76].
- In addition, <productname>Postgres</productname>
+ In addition, <productname>PostgreSQL</productname>
can use a hash-join algorithm along
the lines of [SHAP86]; however, it must know whether this
strategy is applicable. The current hash-join algorithm
</para>
<para>
If other join strategies are found to be practical,
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
will change the optimizer and run-time system to use
them and will require additional specification when an
operator is defined. Fortunately, the research community
MYBOXES.description <<< box '((0,0), (1,1))'
</programlisting>
is present in the qualification,
- then <productname>Postgres</productname> may have to
+ then <productname>PostgreSQL</productname> may have to
estimate the fraction of the instances in MYBOXES that
satisfy the clause. The function
<replaceable class="parameter">res_proc</replaceable>
<programlisting>
MYBOXES.description === box '((0,0), (1,1))'
</programlisting>
- is that <productname>Postgres</productname>
+ is that <productname>PostgreSQL</productname>
attempts to optimize operators and can
decide to use an index to restrict the search space when
operators are involved. However, there is no attempt to
<para>
<command>CREATE OPERATOR</command>
- is a <productname>Postgres</productname> extension.
+ is a <productname>PostgreSQL</productname> extension.
There is no <command>CREATE OPERATOR</command>
statement in <acronym>SQL92</acronym>.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATERULE">
</title>
<para>
- The <productname>Postgres</productname>
+ The <productname>PostgreSQL</productname>
<firstterm>rule system</firstterm> allows one to define an
alternate action to be performed on inserts, updates, or deletions
from database tables. Rules are used to
It is very important to take care to avoid circular rules.
For example, though each
of the following two rule definitions are accepted by
- <productname>Postgres</productname>, the
- select command will cause <productname>Postgres</productname> to
+ <productname>PostgreSQL</productname>, the
+ select command will cause <productname>PostgreSQL</productname> to
report an error because the query cycled too many times:
<programlisting>
</programlisting>
This attempt to select from EMP will cause
- <productname>Postgres</productname> to issue an error
+ <productname>PostgreSQL</productname> to issue an error
because the queries cycled too many times:
<programlisting>
</title>
<para>
- <command>CREATE RULE</command> statement is a <productname>Postgres</productname>
+ <command>CREATE RULE</command> statement is a <productname>PostgreSQL</productname>
language extension.
There is no <command>CREATE RULE</command> statement in <acronym>SQL92</acronym>.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATESEQUENCE">
</title>
<para>
- <command>CREATE SEQUENCE</command> is a <productname>Postgres</productname>
+ <command>CREATE SEQUENCE</command> is a <productname>PostgreSQL</productname>
language extension.
There is no <command>CREATE SEQUENCE</command> statement
in <acronym>SQL92</acronym>.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATETABLE">
</para>
<!--
<para>
- Postgres automatically allows the created table to inherit
+ <application>PostgreSQL</application> automatically allows the
+ created table to inherit
functions on tables above it in the inheritance hierarchy; that
is, if we create table <literal>foo</literal> inheriting from
<literal>bar</literal>, then functions that accept the tuple
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATETABLEAS">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATETRIGGER">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATETYPE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEUSER">
<listitem>
<para>
The <literal>SYSID</literal> clause can be used to choose
- the <productname>Postgres</productname> user id of the user
+ the <productname>PostgreSQL</productname> user id of the user
that is being created. It is not at all necessary that those
match the <acronym>UNIX</acronym> user ids, but some people
choose to keep the numbers the same.
</title>
<para>
<command>CREATE USER</command> will add a new user to an instance of
- <productname>Postgres</productname>. Refer to the administrator's
+ <productname>PostgreSQL</productname>. Refer to the administrator's
guide for information about managing users and authentication.
You must be a database superuser to use this command.
</para>
endterm="SQL-DROPUSER-title"> to remove a user.
Use <xref linkend="SQL-ALTERGROUP" endterm="SQL-ALTERGROUP-title">
to add or remove the user from other groups.
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
comes with a script <xref linkend="APP-CREATEUSER"
endterm="APP-CREATEUSER-title">
which has the same functionality as this command (in fact, it calls this command)
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-CREATEVIEW">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-CREATEDB">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-CREATELANG">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-CREATEUSER">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<REFENTRY ID="SQL-CURRENT-TIME">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<REFENTRY ID="SQL-CURRENT-TIMESTAMP">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<REFENTRY ID="SQL-CURRENT-USER">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DECLARE">
<acronym>SQL92</acronym> keyword indicating that data retrieved
from the cursor should be unaffected by updates from other processes or cursors.
Since cursor operations occur within transactions
- in <productname>Postgres</productname> this is always the case.
+ in <productname>PostgreSQL</productname> this is always the case.
This keyword has no effect.
</para>
</listitem>
<para>
<acronym>SQL92</acronym> keyword indicating that data may be retrieved
in multiple rows per FETCH operation. Since this is allowed at all times
- by <productname>Postgres</productname> this keyword has no effect.
+ by <productname>PostgreSQL</productname> this keyword has no effect.
</para>
</listitem>
</varlistentry>
<para>
<acronym>SQL92</acronym> keyword indicating that the cursor will be used
in a read only mode. Since this is the only cursor access mode
- available in <productname>Postgres</productname> this keyword has no effect.
+ available in <productname>PostgreSQL</productname> this keyword has no effect.
</para>
</listitem>
</varlistentry>
<para>
<acronym>SQL92</acronym> keyword indicating that the cursor will be used
to update tables. Since cursor updates are not currently
- supported in <productname>Postgres</productname> this keyword
+ supported in <productname>PostgreSQL</productname> this keyword
provokes an informational error message.
</para>
</listitem>
<para>
Column(s) to be updated.
Since cursor updates are not currently
- supported in <productname>Postgres</productname> the UPDATE clause
+ supported in <productname>PostgreSQL</productname> the UPDATE clause
provokes an informational error message.
</para>
</listitem>
<para>
Normal cursors return data in text format, either ASCII or another
- encoding scheme depending on how the <productname>Postgres</productname>
+ encoding scheme depending on how the <productname>PostgreSQL</productname>
backend was built. Since
data is stored natively in binary format, the system must
do a conversion to produce the text format. In addition,
<para>
String representation is architecture-neutral whereas binary
representation can differ between different machine architectures.
- <emphasis><productname>Postgres</productname> does not resolve
+ <emphasis><productname>PostgreSQL</productname> does not resolve
byte ordering or representation issues for binary cursors</emphasis>.
Therefore, if your client machine and server machine use different
representations (e.g., <quote>big-endian</quote> versus <quote>little-endian</quote>),
<para>
In <acronym>SQL92</acronym> cursors are only available in
embedded <acronym>SQL</acronym> (<acronym>ESQL</acronym>) applications.
- The <productname>Postgres</productname> backend
+ The <productname>PostgreSQL</productname> backend
does not implement an explicit <command>OPEN cursor</command>
statement; a cursor is considered to be open when it is declared.
However, <application>ecpg</application>, the
- embedded SQL preprocessor for <productname>Postgres</productname>,
+ embedded SQL preprocessor for <productname>PostgreSQL</productname>,
supports the <acronym>SQL92</acronym> cursor conventions, including those
involving DECLARE and OPEN statements.
</para>
</title>
<para>
<acronym>SQL92</acronym> allows cursors only in embedded <acronym>SQL</acronym>
- and in modules. <productname>Postgres</productname> permits cursors to be used
+ and in modules. <productname>PostgreSQL</productname> permits cursors to be used
interactively.
<acronym>SQL92</acronym> allows embedded or modular cursors to
update database information.
- All <productname>Postgres</productname> cursors are read only.
- The BINARY keyword is a <productname>Postgres</productname> extension.
+ All <productname>PostgreSQL</productname> cursors are read only.
+ The BINARY keyword is a <productname>PostgreSQL</productname> extension.
</para>
</refsect2>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DELETE">
<tip>
<para>
<xref linkend="sql-truncate" endterm="sql-truncate-title"> is a
- <productname>Postgres</productname> extension which provides a
+ <productname>PostgreSQL</productname> extension which provides a
faster mechanism to remove all rows from a table.
</para>
</tip>
where <replaceable class="parameter">cursor</replaceable>
identifies an open cursor.
- Interactive cursors in <productname>Postgres</productname> are read-only.
+ Interactive cursors in <productname>PostgreSQL</productname> are read-only.
</para>
</refsect2>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPAGGREGATE">
<para>
There is no <command>DROP AGGREGATE</command> statement
in <acronym>SQL92</acronym>; the statement is a
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
language extension.
</para>
</refsect2>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPDATABASE">
<para>
<command>DROP DATABASE</command> statement is a
- <productname>Postgres</productname> language extension;
+ <productname>PostgreSQL</productname> language extension;
there is no such command in <acronym>SQL92</acronym>.
</para>
</refsect2>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPFUNCTION">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPGROUP">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPINDEX">
Notes
</title>
<para>
- <command>DROP INDEX</command> is a <productname>Postgres</productname>
+ <command>DROP INDEX</command> is a <productname>PostgreSQL</productname>
language extension.
</para>
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPLANGUAGE">
</title>
<para>
The <command>DROP PROCEDURAL LANGUAGE</command> statement is
- a <productname>Postgres</productname> language extension.
+ a <productname>PostgreSQL</productname> language extension.
</para>
<para>
Refer to
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPOPERATOR">
</title>
<para>
The <command>DROP OPERATOR</command> statement is a
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
language extension.
</para>
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPRULE">
</title>
<para>
<command>DROP RULE</command> drops a rule from the specified
- <productname>Postgres</productname> rule
- system. <productname>Postgres</productname>
+ <productname>PostgreSQL</productname> rule
+ system. <productname>PostgreSQL</productname>
will immediately cease enforcing it and
will purge its definition from the system catalogs.
</para>
</title>
<para>
The <command>DROP RULE</command> statement is a
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
language extension.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPSEQUENCE">
</title>
<para>
The <command>DROP SEQUENCE</command> statement is a
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
language extension.
</para>
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPTABLE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPTRIGGER">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPTYPE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPUSER">
Use <xref linkend="SQL-CREATEUSER" endterm="SQL-CREATEUSER-title">
to add new users, and <xref linkend="SQL-ALTERUSER"
endterm="SQL-ALTERUSER-title"> to change a user's properties.
- <productname>Postgres</productname>
+ <productname>PostgreSQL</productname>
comes with a script <xref linkend="APP-DROPUSER"
endterm="APP-DROPUSER-title">
which has the same functionality as this command (in fact, it calls this command)
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-DROPVIEW">
</title>
<para>
At present, to remove a referenced view from a
- <productname>Postgres</productname> database,
+ <productname>PostgreSQL</productname> database,
you must drop it explicitly.
</para>
</refsect3>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-DROPDB">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-DROPLANG">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-DROPUSER">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-ECPG">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-END">
</title>
<para>
- <command>END</command> is a <productname>Postgres</productname>
+ <command>END</command> is a <productname>PostgreSQL</productname>
extension, and is a synonym for the SQL92-compatible
<xref linkend="sql-commit" endterm="sql-commit-title">.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-EXPLAIN">
</computeroutput></term>
<listitem>
<para>
- Explicit query plan from the <productname>Postgres</productname> backend.
+ Explicit query plan from the <productname>PostgreSQL</productname> backend.
</para>
</listitem>
</varlistentry>
</title>
<para>
- This command displays the execution plan that the Postgres planner
+ This command displays the execution plan that the
+ <application>PostgreSQL</application> planner
generates for the supplied query. The execution plan shows how
the table(s) referenced by the query will be scanned---by plain
sequential scan, index scan, etc.---and if multiple tables are
<para>
The VERBOSE option emits the full internal representation of the plan tree,
rather than just a summary (and sends it to the postmaster log file, too).
- Usually this option is only useful for debugging Postgres.
+ Usually this option is only useful for debugging
+ <application>PostgreSQL</application>.
</para>
<caution>
</title>
<para>
There is only sparse documentation on the optimizer's use of cost
- information in <productname>Postgres</productname>.
+ information in <productname>PostgreSQL</productname>.
Refer to the <citetitle>User's Guide</citetitle> and
<citetitle>Programmer's Guide</citetitle> for more information.
</para>
<para>
Note that the specific numbers shown, and even the selected query
- strategy, may vary between Postgres releases due to planner improvements.
+ strategy, may vary between <application>PostgreSQL</application>
+ releases due to planner improvements.
</para>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-FETCH">
</computeroutput></term>
<listitem>
<para>
- <productname>Postgres</productname> does not support absolute
+ <productname>PostgreSQL</productname> does not support absolute
positioning of cursors.
</para>
</listitem>
</para>
<para>
- <productname>Postgres</productname> does not currently support
+ <productname>PostgreSQL</productname> does not currently support
this notion; in fact the value zero is reserved to indicate that
all rows should be retrieved and is equivalent to specifying the ALL keyword.
- If the RELATIVE keyword has been used, <productname>Postgres</productname>
+ If the RELATIVE keyword has been used, <productname>PostgreSQL</productname>
assumes that the user intended <acronym>SQL92</acronym> behavior
and returns this error message.
</para>
<para>
Note that the FORWARD and BACKWARD keywords are
- <productname>Postgres</productname> extensions.
+ <productname>PostgreSQL</productname> extensions.
The <acronym>SQL92</acronym> syntax is also supported, specified
in the second form of the command. See below for details
on compatibility issues.
<para>
Updating data in a cursor is not supported by
- <productname>Postgres</productname>,
+ <productname>PostgreSQL</productname>,
because mapping cursor updates back to base tables is
not generally possible, as is also the case with VIEW updates.
Consequently,
<para>
<note>
<para>
- The non-embedded use of cursors is a <productname>Postgres</productname>
+ The non-embedded use of cursors is a <productname>PostgreSQL</productname>
extension. The syntax and usage of cursors is being compared
against the embedded form of cursors defined in <acronym>SQL92</acronym>.
</para>
<listitem>
<para>
The cursor should be positioned to the specified absolute
- row number. All row numbers in <productname>Postgres</productname>
+ row number. All row numbers in <productname>PostgreSQL</productname>
are relative numbers so this capability is not supported.
</para>
</listitem>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-GRANT">
<title>Notes</title>
<para>
- Currently, to grant privileges in <productname>Postgres</productname>
+ Currently, to grant privileges in <productname>PostgreSQL</productname>
to only a few columns, you must
create a view having the desired columns and then grant privileges
to that view.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-INITDB">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-INITLOCATION">
<title>Description</title>
<para>
<application>initlocation</application>
- creates a new <productname>Postgres</productname> secondary database storage area.
+ creates a new <productname>PostgreSQL</productname> secondary database storage area.
See the discussion under <xref linkend="SQL-CREATEDATABASE" endterm="SQL-CREATEDATABASE-title">
about how to manage and use secondary storage areas. If the argument does not contain
a slash and is not valid as a path, it is assumed to be an environment variable,
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-INSERT">
<para>
Each column not present in the target list will be inserted
using a default value, either a declared DEFAULT value
- or NULL. <productname>Postgres</productname> will reject the new
+ or NULL. <productname>PostgreSQL</productname> will reject the new
column if a NULL is inserted into a column declared NOT NULL.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-IPCCLEAN">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-LISTEN">
<para>
<command>LISTEN</command> registers the current
- <productname>Postgres</productname> backend as a
+ <productname>PostgreSQL</productname> backend as a
listener on the notify condition
<replaceable class="PARAMETER">name</replaceable>.
</para>
<para>
The method a frontend application must use to detect notify events depends on
- which <productname>Postgres</productname> application programming interface it
+ which <productname>PostgreSQL</productname> application programming interface it
uses. With the basic libpq library, the application issues
<command>LISTEN</command> as an ordinary SQL command, and then must
periodically call the routine <function>PQnotifies</function> to find out
</para>
<para>
In some previous releases of
- <productname>Postgres</productname>,
+ <productname>PostgreSQL</productname>,
<replaceable class="PARAMETER">name</replaceable>
had to be enclosed in double-quotes when it did not correspond to any existing
table name, even if syntactically valid as a name. That is no longer required.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-LOCK">
<para>
<command>LOCK TABLE</command> controls concurrent access to a table
for the duration of a transaction.
- <productname>Postgres</productname> always uses the least restrictive
+ <productname>PostgreSQL</productname> always uses the least restrictive
lock mode whenever possible. <command>LOCK TABLE</command>
provides for cases when you might need more restrictive locking.
</para>
<note>
<para>
- <productname>Postgres</productname> does detect deadlocks and will
+ <productname>PostgreSQL</productname> does detect deadlocks and will
rollback at least one waiting transaction to resolve the deadlock.
</para>
</note>
</title>
<para>
- <command>LOCK</command> is a <productname>Postgres</productname>
+ <command>LOCK</command> is a <productname>PostgreSQL</productname>
language extension.
</para>
<para>
Except for ACCESS SHARE, ACCESS EXCLUSIVE, and SHARE UPDATE EXCLUSIVE lock
- modes, the <productname>Postgres</productname> lock modes and the
+ modes, the <productname>PostgreSQL</productname> lock modes and the
<command>LOCK TABLE</command> syntax are compatible with those
present in <productname>Oracle</productname>.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-MOVE">
</title>
<para>
- <command>MOVE</command> is a <productname>Postgres</productname>
+ <command>MOVE</command> is a <productname>PostgreSQL</productname>
language extension.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-NOTIFY">
<para>
<command>NOTIFY</command> provides a simple form of signal or
IPC (interprocess communication) mechanism for a collection of processes
- accessing the same <productname>Postgres</productname> database.
+ accessing the same <productname>PostgreSQL</productname> database.
Higher-level mechanisms can be built by using tables in the database to
pass additional data (beyond a mere condition name) from notifier to
listener(s).
notify event, just like all the other listening frontends. Depending on the
application logic, this could result in useless work---for example,
re-reading a database table to find the same updates that that frontend just
- wrote out. In <productname>Postgres</productname> 6.4 and later, it is
+ wrote out. In <productname>PostgreSQL</productname> 6.4 and later, it is
possible to avoid such extra work by noticing whether the notifying backend
process's PID (supplied in the notify event message) is the same as one's own
backend's PID (available from libpq). When they are the same, the notify
event is one's own work bouncing back, and can be ignored. (Despite what was
said in the preceding paragraph, this is a safe technique.
- <productname>Postgres</productname> keeps self-notifies separate from notifies
+ <productname>PostgreSQL</productname> keeps self-notifies separate from notifies
arriving from other backends, so you cannot miss an outside notify by ignoring
your own notifies.)
</para>
</para>
<para>
In some previous releases of
- <productname>Postgres</productname>,
+ <productname>PostgreSQL</productname>,
<replaceable class="PARAMETER">name</replaceable>
had to be enclosed in double-quotes when it did not correspond to any existing
table name, even if syntactically valid as a name. That is no longer required.
</para>
<para>
- In <productname>Postgres</productname> releases prior to 6.4, the backend
+ In <productname>PostgreSQL</productname> releases prior to 6.4, the backend
PID delivered in a notify message was always the PID of the frontend's own
backend. So it was not possible to distinguish one's own notifies from other
clients' notifies in those earlier releases.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="app-pg-ctl">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PGDUMP">
<para>
The <command>pg_dump</command> utility first appeared in
- <application>Postgres95 release 0.02</application>. The
+ <application>Postgres95</application> release <literal>0.02</literal>. The
non-plain-text output formats were introduced in
- <application>PostgreSQL 7.1</application>.
+ <application>PostgreSQL</application> release <literal>7.1</literal>.
</para>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PG-DUMPALL">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PG-PASSWD">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PG-UPGRADE">
<para>
<application>pg_upgrade</application>
is a utility for upgrading from a previous
- Postgres release without reloading all the data.
- Not all <productname>Postgres</productname> release transitions can be
+ <productname>PostgreSQL</productname> release without reloading all the data.
+ Not all <productname>PostgreSQL</productname> release transitions can be
handled this way. Check the release notes for details on your installation.
</para>
<procedure>
- <title>Upgrading <productname>Postgres</productname> with pg_upgrade</title>
+ <title>Upgrading <productname>PostgreSQL</productname> with pg_upgrade</title>
<step performance="required">
<para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PGACCESS">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PGTCLSH">
<para>
<command>pgtclsh</command> is a <application>Tcl</application>
shell interface extended with
- <productname>Postgres</productname> database access functions.
+ <productname>PostgreSQL</productname> database access functions.
(Essentially, it is <command>tclsh</command> with
<filename>libpgtcl</filename> loaded.) Like with the regular
<application>Tcl</application> shell, the first command line
<para>
A <application>Tcl</application> shell with
<application>Tk</application> and
- <productname>Postgres</productname> functions is available as <xref
+ <productname>PostgreSQL</productname> functions is available as <xref
linkend="app-pgtksh">.
</para>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PGTKSH">
<para>
<command>pgtksh</command> is a <application>Tcl/Tk</application>
- shell interface extended with <productname>Postgres</productname>
+ shell interface extended with <productname>PostgreSQL</productname>
database access functions. (Essentially, it is
<command>wish</command> with <filename>libpgtcl</filename> loaded.)
Like with <command>wish</command>, the regular
<para>
A plain <application>Tcl</application> shell with
- <productname>Postgres</productname> functions is available as <xref
+ <productname>PostgreSQL</productname> functions is available as <xref
linkend="app-pgtclsh">.
</para>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-POSTGRES">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="app-postmaster">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-PSQL">
<para>
<application>psql</application> is a terminal-based front-end to
- <productname>Postgres</productname>. It enables you to type in queries
- interactively, issue them to <productname>Postgres</productname>, and see
+ <productname>PostgreSQL</productname>. It enables you to type in queries
+ interactively, issue them to <productname>PostgreSQL</productname>, and see
the query results. Alternatively, input can be from a file.
In addition, it provides a number of meta-commands and
various shell-like features to facilitate writing scripts and automating a wide
<title>Connecting To A Database</title>
<para>
- <application>psql</application> is a regular <productname>Postgres</productname>
+ <application>psql</application> is a regular <productname>PostgreSQL</productname>
client application. In order to connect to a database you need to know the
name of your target database, the hostname and port number of the server
and what user name you want to connect as. <application>psql</application> can be
<term><literal>\copyright</literal></term>
<listitem>
<para>
- Shows the copyright and distribution terms of <application>Postgres</application>.
+ Shows the copyright and distribution terms of <application>PostgreSQL</application>.
</para>
</listitem>
</varlistentry>
<note>
<para>
- <productname>Postgres</productname> stores the object descriptions in the
+ <productname>PostgreSQL</productname> stores the object descriptions in the
pg_description system table.
</para>
</note>
<para>
List all the databases in the server as well as their owners. Append a
<quote>+</quote> to the command name to see any descriptions
- for the databases as well. If your <productname>Postgres</productname>
+ for the databases as well. If your <productname>PostgreSQL</productname>
installation was
compiled with multibyte encoding support, the encoding scheme of each
database is shown as well.
<listitem>
<para>
- Stores the file into a <productname>Postgres</productname> <quote>large object</quote>.
+ Stores the file into a <productname>PostgreSQL</productname> <quote>large object</quote>.
Optionally, it associates the given comment with the object. Example:
<programlisting>
foo=> <userinput>\lo_import '/home/peter/pictures/photo.xcf' 'a picture of me'</userinput>
<term><literal>\lo_list</literal></term>
<listitem>
<para>
- Shows a list of all <productname>Postgres</productname> <quote>large
+ Shows a list of all <productname>PostgreSQL</productname> <quote>large
objects</quote> currently stored in the database, along with any
comments provided for them.
</para>
<listitem>
<para>
When this variable is set and a backslash command queries the database, the query
- is first shown. This way you can study the <productname>Postgres</productname>
+ is first shown. This way you can study the <productname>PostgreSQL</productname>
internals and provide similar functionality in your own programs. If you set the
variable to the value <quote>noexec</quote>, the queries are just shown but are
not actually sent to the backend and executed.
<term><envar>LO_TRANSACTION</envar></term>
<listitem>
<para>
- If you use the <productname>Postgres</productname> large object
+ If you use the <productname>PostgreSQL</productname> large object
interface to specially store data that does not fit into one tuple,
all the operations must be contained in a transaction block. (See the
documentation of the large object interface for more information.) Since
case you can escape a colon with a backslash to protect it from interpretation.
(The colon syntax for variables is standard <acronym>SQL</acronym> for embedded
query languages, such as <application>ecpg</application>. The colon syntax for
- array slices and type casts are <productname>Postgres</productname> extensions,
+ array slices and type casts are <productname>PostgreSQL</productname> extensions,
hence the conflict.)
</para>
<para>
If you have the readline library installed but <application>psql</application>
- does not seem to use it, you must make sure that <productname>Postgres</productname>'s
+ does not seem to use it, you must make sure that <productname>PostgreSQL</productname>'s
top-level <filename>configure</filename> script finds it. <filename>configure</filename>
needs to find both the library <filename>libreadline.a</filename>
(or a shared library equivalent)
<para>
This section only shows a few examples specific to <application>psql</application>.
If you want to learn <acronym>SQL</acronym> or get familiar with
- <productname>Postgres</productname>, you might wish to read the Tutorial that
+ <productname>PostgreSQL</productname>, you might wish to read the Tutorial that
is included in the distribution.
</para>
</note>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-REINDEX">
(Indeed, in this sort of scenario you may find that backends are
crashing immediately at startup, due to reliance on the corrupted
indexes.) To recover safely, the postmaster must be shut down and a
- stand-alone Postgres backend must be started instead, giving it
+ stand-alone <productname>PostgreSQL</productname> backend must be
+ started instead, giving it
the command-line options -O and -P (these options allow system table
modifications and prevent use of system indexes, respectively). Then
issue <command>REINDEX INDEX</>, <command>REINDEX TABLE</>, or
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-RESET">
<title>Compatibility</title>
<para>
- <command>RESET</command> is a <productname>Postgres</productname> extension.
+ <command>RESET</command> is a <productname>PostgreSQL</productname> extension.
</para>
</refsect1>
</refentry>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-REVOKE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-ROLLBACK">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-SELECT">
from sub-tables (inheritance children) of the table.
<command>ONLY</command> will
suppress rows from sub-tables of the table. Before
- <Productname>Postgres</Productname> 7.1,
+ <Productname>PostgreSQL</Productname> 7.1,
this was the default result, and adding sub-tables was done
by appending <command>*</command> to the table name.
This old behaviour is available via the command
</para>
<para>
- As of <productname>Postgres</productname> 7.0, the
+ As of <productname>PostgreSQL</productname> 7.0, the
query optimizer takes LIMIT into account when generating a query plan,
so you are very likely to get different plans (yielding different row
orders) depending on what you use for LIMIT and OFFSET. Thus, using
</title>
<para>
-<productname>Postgres</productname> allows one to omit
+<productname>PostgreSQL</productname> allows one to omit
the <command>FROM</command> clause from a query. This feature
was retained from the original PostQuel query language. It has
a straightforward use to compute the results of simple constant
SELECT distributors.* FROM distributors d, distributors distributors;
</programlisting>
that he will actually get. To help detect this sort of mistake,
-<Productname>Postgres</Productname> 7.1
+<Productname>PostgreSQL</Productname> 7.1
and later will warn if the implicit-FROM feature is used in a query that also
contains an explicit FROM clause.
In the <acronym>SQL92</acronym> standard, the optional keyword <literal>AS</>
is just noise and can be
omitted without affecting the meaning.
- The <productname>Postgres</productname> parser requires this keyword when
+ The <productname>PostgreSQL</productname> parser requires this keyword when
renaming output columns because the type extensibility features lead to
parsing ambiguities
in this context. <literal>AS</literal> is optional in FROM items, however.</para>
In <acronym>SQL92</acronym>, an ORDER BY clause may only use result
column names or numbers, while a GROUP BY clause may only use input
column names.
- <productname>Postgres</productname> extends each of these clauses to
+ <productname>PostgreSQL</productname> extends each of these clauses to
allow the other choice as well (but it uses the standard's interpretation
if there is ambiguity).
- <productname>Postgres</productname> also allows both clauses to specify
+ <productname>PostgreSQL</productname> also allows both clauses to specify
arbitrary expressions. Note that names appearing in an expression will
always be taken as input-column names, not as result-column names.
</para>
<para>
The CORRESPONDING BY clause is not supported by
- <productname>Postgres</productname>.
+ <productname>PostgreSQL</productname>.
</para>
</refsect3>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-SELECTINTO">
SQL92 uses <command>SELECT ... INTO</command> to represent selecting
values into scalar variables of a host program, rather than creating
a new table. This indeed is the usage found in PL/pgSQL and ecpg.
- The <productname>Postgres</productname> usage of <command>SELECT
+ The <productname>PostgreSQL</productname> usage of <command>SELECT
INTO</command> to represent table creation is historical. It's best
to use <command>CREATE TABLE AS</command> for this purpose in new code.
(<command>CREATE TABLE AS</command> isn't standard either, but it's
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-SET">
<para>
This option is only available if
- <productname>Postgres</productname> is build with multibyte
+ <productname>PostgreSQL</productname> is build with multibyte
support.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>Postgres</term>
+ <term>PostgreSQL</term>
<listitem>
<para>
- Use traditional <productname>Postgres</productname> format.
+ Use traditional <productname>PostgreSQL</productname> format.
</para>
</listitem>
</varlistentry>
<para>
The following two options determine both a substyle of the
- <quote>SQL</quote> and <quote>Postgres</quote> output formats
+ <quote>SQL</quote> and <quote>PostgreSQL</quote> output formats
and the preferred interpretation of ambiguous date input.
<variablelist>
<para>
This option is only available if
- <productname>Postgres</productname> was built with multibyte
+ <productname>PostgreSQL</productname> was built with multibyte
support.
</para>
</listitem>
<refsect1>
<title>Examples</title>
<para>
- Set the style of date to traditional Postgres with European conventions:
+ Set the style of date to traditional
+ <productname>PostgreSQL</productname> with European conventions:
<screen>
-SET DATESTYLE TO Postgres,European;
+SET DATESTYLE TO PostgreSQL,European;
</screen>
Set the time zone for Berkeley, California, using double quotes to
attempts to mimic <acronym>SQL92</acronym>. However, SQL allows
only numeric time zone offsets. All other parameter settings as
well as the first syntax shown above are a
- <productname>Postgres</productname> extension.
+ <productname>PostgreSQL</productname> extension.
</para>
</refsect2>
</refsect1>
<para>
SERIALIZABLE is the default level in <acronym>SQL</acronym>.
- Postgres does not provide the isolation levels <option>READ
- UNCOMMITTED</option> and <option>REPEATABLE READ</option>. Because
+ <productname>PostgreSQL</productname> does not provide the
+ isolation levels <option>READ UNCOMMITTED</option>
+ and <option>REPEATABLE READ</option>. Because
of multi-version concurrency control, the serializable level is not
truly serializable. See the <citetitle>User's Guide</citetitle> for
details.
In <acronym>SQL</acronym> there are two other transaction
characteristics that can be set with these commands: whether the
transaction is read-only and the size of the diagnostics area.
- Neither of these concepts are supported in Postgres.
+ Neither of these concepts are supported in
+ <productname>PostgreSQL</productname>.
</para>
</refsect2>
</refsect1>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-SHOW">
<para>
The <command>SHOW</command> command is a
- <productname>Postgres</productname> extension.
+ <productname>PostgreSQL</productname> extension.
</para>
</refsect1>
</refentry>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-TRUNCATE">
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-UNLISTEN">
<command>UNLISTEN</command>
is used to remove an existing <command>NOTIFY</command> registration.
UNLISTEN cancels any existing registration of the current
- <productname>Postgres</productname> session as a listener on the notify
+ <productname>PostgreSQL</productname> session as a listener on the notify
condition <replaceable class="PARAMETER">notifyname</replaceable>.
The special condition wildcard <literal>*</literal> cancels all listener registrations
for the current session.
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-UPDATE">
<term><replaceable class="PARAMETER">fromlist</replaceable></term>
<listitem>
<para>
- A <productname>Postgres</productname>
+ A <productname>PostgreSQL</productname>
non-standard extension to allow columns
from other tables to appear in the WHERE condition.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="SQL-VACUUM">
</title>
<para>
<command>VACUUM</command> reclaims storage occupied by deleted tuples.
- In normal <productname>Postgres</productname> operation, tuples that
+ In normal <productname>PostgreSQL</productname> operation, tuples that
are DELETEd or obsoleted by UPDATE are not physically removed from
their table; they remain present until a <command>VACUUM</command> is
done. Therefore it's necessary to do <command>VACUUM</command>
ANALYZE</command> command for the affected table. This will update the
system catalogs with
the results of all recent changes, and allow the
- <productname>Postgres</productname> query optimizer to make better
+ <productname>PostgreSQL</productname> query optimizer to make better
choices in planning user queries.
</para>
<!--
$Header$
-Postgres documentation
+PostgreSQL documentation
-->
<refentry id="APP-VACUUMDB">
projects / users / bernd / postgres.git / commitdiff