Spell checking, consistent terminology.
This commit is contained in:
parent
4240d2bffd
commit
8442a92e5a
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.23 2003/11/01 01:56:28 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="overview">
|
<chapter id="overview">
|
||||||
@ -99,11 +99,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
<para>
|
<para>
|
||||||
The executor recursively steps through
|
The executor recursively steps through
|
||||||
the <firstterm>plan tree</firstterm> and
|
the <firstterm>plan tree</firstterm> and
|
||||||
retrieves tuples in the way represented by the plan.
|
retrieves rows in the way represented by the plan.
|
||||||
The executor makes use of the
|
The executor makes use of the
|
||||||
<firstterm>storage system</firstterm> while scanning
|
<firstterm>storage system</firstterm> while scanning
|
||||||
relations, performs <firstterm>sorts</firstterm> and <firstterm>joins</firstterm>,
|
relations, performs <firstterm>sorts</firstterm> and <firstterm>joins</firstterm>,
|
||||||
evaluates <firstterm>qualifications</firstterm> and finally hands back the tuples derived.
|
evaluates <firstterm>qualifications</firstterm> and finally hands back the rows derived.
|
||||||
</para>
|
</para>
|
||||||
</step>
|
</step>
|
||||||
</procedure>
|
</procedure>
|
||||||
@ -150,7 +150,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
to the <firstterm>backend</firstterm> (server). The query is transmitted using plain text,
|
to the <firstterm>backend</firstterm> (server). The query is transmitted using plain text,
|
||||||
i.e. there is no parsing done in the <firstterm>frontend</firstterm> (client). The
|
i.e. there is no parsing done in the <firstterm>frontend</firstterm> (client). The
|
||||||
server parses the query, creates an <firstterm>execution plan</firstterm>,
|
server parses the query, creates an <firstterm>execution plan</firstterm>,
|
||||||
executes the plan and returns the retrieved tuples to the client
|
executes the plan and returns the retrieved rows to the client
|
||||||
by transmitting them over the established connection.
|
by transmitting them over the established connection.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
@ -195,8 +195,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
The <firstterm>lexer</firstterm> is defined in the file
|
The <firstterm>lexer</firstterm> is defined in the file
|
||||||
<filename>scan.l</filename> and is responsible
|
<filename>scan.l</filename> and is responsible
|
||||||
for recognizing <firstterm>identifiers</firstterm>,
|
for recognizing <firstterm>identifiers</firstterm>,
|
||||||
the <firstterm>SQL keywords</firstterm> etc. For
|
the <firstterm>SQL key words</firstterm> etc. For
|
||||||
every keyword or identifier that is found, a <firstterm>token</firstterm>
|
every key word or identifier that is found, a <firstterm>token</firstterm>
|
||||||
is generated and handed to the parser.
|
is generated and handed to the parser.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -278,7 +278,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
call. This may be transformed to either a <structname>FuncExpr</>
|
call. This may be transformed to either a <structname>FuncExpr</>
|
||||||
or <structname>Aggref</> node depending on whether the referenced
|
or <structname>Aggref</> node depending on whether the referenced
|
||||||
name turns out to be an ordinary function or an aggregate function.
|
name turns out to be an ordinary function or an aggregate function.
|
||||||
Also, information about the actual datatypes of columns and expression
|
Also, information about the actual data types of columns and expression
|
||||||
results is added to the query tree.
|
results is added to the query tree.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
@ -297,9 +297,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The first one worked using <firstterm>tuple level</firstterm> processing and was
|
The first one worked using <firstterm>row level</firstterm> processing and was
|
||||||
implemented deep in the <firstterm>executor</firstterm>. The rule system was
|
implemented deep in the <firstterm>executor</firstterm>. The rule system was
|
||||||
called whenever an individual tuple had been accessed. This
|
called whenever an individual row had been accessed. This
|
||||||
implementation was removed in 1995 when the last official release
|
implementation was removed in 1995 when the last official release
|
||||||
of the <productname>Berkeley Postgres</productname> project was
|
of the <productname>Berkeley Postgres</productname> project was
|
||||||
transformed into <productname>Postgres95</productname>.
|
transformed into <productname>Postgres95</productname>.
|
||||||
@ -396,11 +396,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<firstterm>nested loop join</firstterm>: The right relation is scanned
|
<firstterm>nested loop join</firstterm>: The right relation is scanned
|
||||||
once for every tuple found in the left relation. This strategy
|
once for every row found in the left relation. This strategy
|
||||||
is easy to implement but can be very time consuming. (However,
|
is easy to implement but can be very time consuming. (However,
|
||||||
if the right relation can be scanned with an indexscan, this can
|
if the right relation can be scanned with an index scan, this can
|
||||||
be a good strategy. It is possible to use values from the current
|
be a good strategy. It is possible to use values from the current
|
||||||
row of the left relation as keys for the indexscan of the right.)
|
row of the left relation as keys for the index scan of the right.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
@ -419,8 +419,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
<firstterm>hash join</firstterm>: the right relation is first scanned
|
<firstterm>hash join</firstterm>: the right relation is first scanned
|
||||||
and loaded into a hash table, using its join attributes as hash keys.
|
and loaded into a hash table, using its join attributes as hash keys.
|
||||||
Next the left relation is scanned and the
|
Next the left relation is scanned and the
|
||||||
appropriate values of every tuple found are used as hash keys to
|
appropriate values of every row found are used as hash keys to
|
||||||
locate the matching tuples in the table.
|
locate the matching rows in the table.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@ -428,7 +428,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The finished plan tree consists of sequential or index scans of
|
The finished plan tree consists of sequential or index scans of
|
||||||
the base relations, plus nestloop, merge, or hash join nodes as
|
the base relations, plus nested-loop, merge, or hash join nodes as
|
||||||
needed, plus any auxiliary steps needed, such as sort nodes or
|
needed, plus any auxiliary steps needed, such as sort nodes or
|
||||||
aggregate-function calculation nodes. Most of these plan node
|
aggregate-function calculation nodes. Most of these plan node
|
||||||
types have the additional ability to do <firstterm>selection</>
|
types have the additional ability to do <firstterm>selection</>
|
||||||
@ -451,26 +451,26 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
The <firstterm>executor</firstterm> takes the plan handed back by the
|
The <firstterm>executor</firstterm> takes the plan handed back by the
|
||||||
planner/optimizer and recursively processes it to extract the required set
|
planner/optimizer and recursively processes it to extract the required set
|
||||||
of rows. This is essentially a demand-pull pipeline mechanism.
|
of rows. This is essentially a demand-pull pipeline mechanism.
|
||||||
Each time a plan node is called, it must deliver one more tuple, or
|
Each time a plan node is called, it must deliver one more row, or
|
||||||
report that it is done delivering tuples.
|
report that it is done delivering rows.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To provide a concrete example, assume that the top
|
To provide a concrete example, assume that the top
|
||||||
node is a <literal>MergeJoin</literal> node.
|
node is a <literal>MergeJoin</literal> node.
|
||||||
Before any merge can be done two tuples have to be fetched (one from
|
Before any merge can be done two rows have to be fetched (one from
|
||||||
each subplan). So the executor recursively calls itself to
|
each subplan). So the executor recursively calls itself to
|
||||||
process the subplans (it starts with the subplan attached to
|
process the subplans (it starts with the subplan attached to
|
||||||
<literal>lefttree</literal>). The new top node (the top node of the left
|
<literal>lefttree</literal>). The new top node (the top node of the left
|
||||||
subplan) is, let's say, a
|
subplan) is, let's say, a
|
||||||
<literal>Sort</literal> node and again recursion is needed to obtain
|
<literal>Sort</literal> node and again recursion is needed to obtain
|
||||||
an input tuple. The child node of the <literal>Sort</literal> might
|
an input row. The child node of the <literal>Sort</literal> might
|
||||||
be a <literal>SeqScan</> node, representing actual reading of a table.
|
be a <literal>SeqScan</> node, representing actual reading of a table.
|
||||||
Execution of this node causes the executor to fetch a row from the
|
Execution of this node causes the executor to fetch a row from the
|
||||||
table and return it up to the calling node. The <literal>Sort</literal>
|
table and return it up to the calling node. The <literal>Sort</literal>
|
||||||
node will repeatedly call its child to obtain all the rows to be sorted.
|
node will repeatedly call its child to obtain all the rows to be sorted.
|
||||||
When the input is exhausted (as indicated by the child node returning
|
When the input is exhausted (as indicated by the child node returning
|
||||||
a NULL instead of a tuple), the <literal>Sort</literal> code performs
|
a NULL instead of a row), the <literal>Sort</literal> code performs
|
||||||
the sort, and finally is able to return its first output row, namely
|
the sort, and finally is able to return its first output row, namely
|
||||||
the first one in sorted order. It keeps the remaining rows stored so
|
the first one in sorted order. It keeps the remaining rows stored so
|
||||||
that it can deliver them in sorted order in response to later demands.
|
that it can deliver them in sorted order in response to later demands.
|
||||||
@ -508,7 +508,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
|
|||||||
result row. But <command>INSERT ... SELECT</> may demand the full power
|
result row. But <command>INSERT ... SELECT</> may demand the full power
|
||||||
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
|
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
|
||||||
that each computed row includes all the updated column values, plus
|
that each computed row includes all the updated column values, plus
|
||||||
the <firstterm>TID</> (tuple ID, or location) of the original target row;
|
the <firstterm>TID</> (tuple ID, or row ID) of the original target row;
|
||||||
the executor top level uses this information to create a new updated row
|
the executor top level uses this information to create a new updated row
|
||||||
and mark the old row deleted. For <command>DELETE</>, the only column
|
and mark the old row deleted. For <command>DELETE</>, the only column
|
||||||
that is actually returned by the plan is the TID, and the executor top
|
that is actually returned by the plan is the TID, and the executor top
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.31 2003/08/31 17:32:18 petere Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.32 2003/11/01 01:56:28 petere Exp $ -->
|
||||||
|
|
||||||
<sect1 id="arrays">
|
<sect1 id="arrays">
|
||||||
<title>Arrays</title>
|
<title>Arrays</title>
|
||||||
@ -348,9 +348,9 @@ SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
|
|||||||
<para>
|
<para>
|
||||||
When a single element is pushed on to the beginning of a one-dimensional
|
When a single element is pushed on to the beginning of a one-dimensional
|
||||||
array, the result is an array with a lower bound subscript equal to
|
array, the result is an array with a lower bound subscript equal to
|
||||||
the righthand operand's lower bound subscript, minus one. When a single
|
the right-hand operand's lower bound subscript, minus one. When a single
|
||||||
element is pushed on to the end of a one-dimensional array, the result is
|
element is pushed on to the end of a one-dimensional array, the result is
|
||||||
an array retaining the lower bound of the lefthand operand. For example:
|
an array retaining the lower bound of the left-hand operand. For example:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT array_dims(1 || ARRAY[2,3]);
|
SELECT array_dims(1 || ARRAY[2,3]);
|
||||||
array_dims
|
array_dims
|
||||||
@ -368,9 +368,9 @@ SELECT array_dims(ARRAY[1,2] || 3);
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
When two arrays with an equal number of dimensions are concatenated, the
|
When two arrays with an equal number of dimensions are concatenated, the
|
||||||
result retains the lower bound subscript of the lefthand operand's outer
|
result retains the lower bound subscript of the left-hand operand's outer
|
||||||
dimension. The result is an array comprising every element of the lefthand
|
dimension. The result is an array comprising every element of the left-hand
|
||||||
operand followed by every element of the righthand operand. For example:
|
operand followed by every element of the right-hand operand. For example:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
|
SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
|
||||||
array_dims
|
array_dims
|
||||||
|
@ -1,6 +1,6 @@
|
|||||||
<!--
|
<!--
|
||||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.76 2003/10/17 22:38:20 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.77 2003/11/01 01:56:28 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="catalogs">
|
<chapter id="catalogs">
|
||||||
@ -755,9 +755,9 @@
|
|||||||
<entry><type>int4</type></entry>
|
<entry><type>int4</type></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Always -1 in storage, but when loaded into a tuple descriptor
|
Always -1 in storage, but when loaded into a row descriptor
|
||||||
in memory this may be updated to cache the offset of the attribute
|
in memory this may be updated to cache the offset of the attribute
|
||||||
within the tuple.
|
within the row.
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -800,9 +800,9 @@
|
|||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>
|
<entry>
|
||||||
If true, this attribute is a set. In that case, what is really
|
If true, this attribute is a set. In that case, what is really
|
||||||
stored in the attribute is the OID of a tuple in the
|
stored in the attribute is the OID of a row in the
|
||||||
<structname>pg_proc</structname> catalog. The
|
<structname>pg_proc</structname> catalog. The
|
||||||
<structname>pg_proc</structname> tuple contains the query
|
<structname>pg_proc</structname> row contains the query
|
||||||
string that defines this set, i.e., the query to run to get
|
string that defines this set, i.e., the query to run to get
|
||||||
the set. So the <structfield>atttypid</structfield> (see
|
the set. So the <structfield>atttypid</structfield> (see
|
||||||
above) refers to the type returned by this query, but the
|
above) refers to the type returned by this query, but the
|
||||||
@ -1046,7 +1046,7 @@
|
|||||||
<entry><type>float4</type></entry>
|
<entry><type>float4</type></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of tuples in the table.
|
Number of rows in the table.
|
||||||
This is only an estimate used by the planner.
|
This is only an estimate used by the planner.
|
||||||
It is updated by <command>VACUUM</command>,
|
It is updated by <command>VACUUM</command>,
|
||||||
<command>ANALYZE</command>, and <command>CREATE INDEX</command>.
|
<command>ANALYZE</command>, and <command>CREATE INDEX</command>.
|
||||||
@ -1553,7 +1553,7 @@
|
|||||||
<entry><type>xid</type></entry>
|
<entry><type>xid</type></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>
|
<entry>
|
||||||
All tuples inserted or deleted by transaction IDs before this one
|
All rows inserted or deleted by transaction IDs before this one
|
||||||
have been marked as known committed or known aborted in this database.
|
have been marked as known committed or known aborted in this database.
|
||||||
This is used to determine when commit-log space can be recycled.
|
This is used to determine when commit-log space can be recycled.
|
||||||
</entry>
|
</entry>
|
||||||
@ -1564,7 +1564,7 @@
|
|||||||
<entry><type>xid</type></entry>
|
<entry><type>xid</type></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>
|
<entry>
|
||||||
All tuples inserted by transaction IDs before this one have been
|
All rows inserted by transaction IDs before this one have been
|
||||||
relabeled with a permanent (<quote>frozen</>) transaction ID in this
|
relabeled with a permanent (<quote>frozen</>) transaction ID in this
|
||||||
database. This is useful to check whether a database must be vacuumed
|
database. This is useful to check whether a database must be vacuumed
|
||||||
soon to avoid transaction ID wrap-around problems.
|
soon to avoid transaction ID wrap-around problems.
|
||||||
@ -1666,7 +1666,7 @@
|
|||||||
<row>
|
<row>
|
||||||
<entry><structfield>refobjid</structfield></entry>
|
<entry><structfield>refobjid</structfield></entry>
|
||||||
<entry><type>oid</type></entry>
|
<entry><type>oid</type></entry>
|
||||||
<entry>any oid attribute</entry>
|
<entry>any OID column</entry>
|
||||||
<entry>The OID of the specific referenced object</entry>
|
<entry>The OID of the specific referenced object</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -1945,7 +1945,7 @@
|
|||||||
<row>
|
<row>
|
||||||
<entry><structfield>indkey</structfield></entry>
|
<entry><structfield>indkey</structfield></entry>
|
||||||
<entry><type>int2vector</type></entry>
|
<entry><type>int2vector</type></entry>
|
||||||
<entry><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</entry>
|
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></entry>
|
||||||
<entry>
|
<entry>
|
||||||
This is an array of <structfield>indnatts</structfield> (up to
|
This is an array of <structfield>indnatts</structfield> (up to
|
||||||
<symbol>INDEX_MAX_KEYS</symbol>) values that indicate which
|
<symbol>INDEX_MAX_KEYS</symbol>) values that indicate which
|
||||||
@ -2407,7 +2407,7 @@
|
|||||||
<entry><structfield>opcamid</structfield></entry>
|
<entry><structfield>opcamid</structfield></entry>
|
||||||
<entry><type>oid</type></entry>
|
<entry><type>oid</type></entry>
|
||||||
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
|
<entry><literal><link linkend="catalog-pg-am"><structname>pg_am</structname></link>.oid</literal></entry>
|
||||||
<entry>Index access method opclass is for</entry>
|
<entry>Index access method operator class is for</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -3233,7 +3233,7 @@
|
|||||||
<entry><structfield>tgtype</structfield></entry>
|
<entry><structfield>tgtype</structfield></entry>
|
||||||
<entry><type>int2</type></entry>
|
<entry><type>int2</type></entry>
|
||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry>Bitmask identifying trigger conditions</entry>
|
<entry>Bit mask identifying trigger conditions</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -3534,7 +3534,7 @@
|
|||||||
For types used in system tables, it is critical that the size
|
For types used in system tables, it is critical that the size
|
||||||
and alignment defined in <structname>pg_type</structname>
|
and alignment defined in <structname>pg_type</structname>
|
||||||
agree with the way that the compiler will lay out the column in
|
agree with the way that the compiler will lay out the column in
|
||||||
a struct representing a table row.
|
a structure representing a table row.
|
||||||
</para>
|
</para>
|
||||||
</note></entry>
|
</note></entry>
|
||||||
</row>
|
</row>
|
||||||
@ -3611,8 +3611,8 @@
|
|||||||
<entry></entry>
|
<entry></entry>
|
||||||
<entry><para>
|
<entry><para>
|
||||||
<structfield>typndims</structfield> is the number of array dimensions
|
<structfield>typndims</structfield> is the number of array dimensions
|
||||||
for a domain that is an array (that is, typbasetype is an array type;
|
for a domain that is an array (that is, <structfield>typbasetype</> is an array type;
|
||||||
the domain's typelem will match the base type's typelem).
|
the domain's <structfield>typelem</> will match the base type's <structfield>typelem</structfield>).
|
||||||
Zero for types other than array domains.
|
Zero for types other than array domains.
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.20 2003/10/28 20:18:09 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.21 2003/11/01 01:56:29 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="ddl">
|
<chapter id="ddl">
|
||||||
<title>Data Definition</title>
|
<title>Data Definition</title>
|
||||||
@ -230,9 +230,9 @@ DROP TABLE products;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The identity (transaction ID) of the inserting transaction for
|
The identity (transaction ID) of the inserting transaction for
|
||||||
this tuple. (Note: In this context, a tuple is an individual
|
this row version. (A row version is an individual state of a
|
||||||
state of a row; each update of a row creates a new tuple for the
|
row; each update of a row creates a new row version for the same
|
||||||
same logical row.)
|
logical row.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -260,8 +260,8 @@ DROP TABLE products;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The identity (transaction ID) of the deleting transaction, or
|
The identity (transaction ID) of the deleting transaction, or
|
||||||
zero for an undeleted tuple. It is possible for this column to
|
zero for an undeleted row version. It is possible for this column to
|
||||||
be nonzero in a visible tuple: That usually indicates that the
|
be nonzero in a visible row version: That usually indicates that the
|
||||||
deleting transaction hasn't committed yet, or that an attempted
|
deleting transaction hasn't committed yet, or that an attempted
|
||||||
deletion was rolled back.
|
deletion was rolled back.
|
||||||
</para>
|
</para>
|
||||||
@ -289,9 +289,9 @@ DROP TABLE products;
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The physical location of the tuple within its table. Note that
|
The physical location of the row version within its table. Note that
|
||||||
although the <structfield>ctid</structfield> can be used to
|
although the <structfield>ctid</structfield> can be used to
|
||||||
locate the tuple very quickly, a row's
|
locate the row version very quickly, a row's
|
||||||
<structfield>ctid</structfield> will change each time it is
|
<structfield>ctid</structfield> will change each time it is
|
||||||
updated or moved by <command>VACUUM FULL</>. Therefore
|
updated or moved by <command>VACUUM FULL</>. Therefore
|
||||||
<structfield>ctid</structfield> is useless as a long-term row
|
<structfield>ctid</structfield> is useless as a long-term row
|
||||||
@ -332,7 +332,7 @@ DROP TABLE products;
|
|||||||
of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
|
of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
|
||||||
within a single transaction. In practice this limit is not a
|
within a single transaction. In practice this limit is not a
|
||||||
problem --- note that the limit is on number of
|
problem --- note that the limit is on number of
|
||||||
<acronym>SQL</acronym> commands, not number of tuples processed.
|
<acronym>SQL</acronym> commands, not number of rows processed.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
@ -1047,7 +1047,7 @@ SELECT name, altitude
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In some cases you may wish to know which table a particular tuple
|
In some cases you may wish to know which table a particular row
|
||||||
originated from. There is a system column called
|
originated from. There is a system column called
|
||||||
<structfield>TABLEOID</structfield> in each table which can tell you the
|
<structfield>TABLEOID</structfield> in each table which can tell you the
|
||||||
originating table:
|
originating table:
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.176 2003/09/30 03:22:33 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/func.sgml,v 1.177 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -541,7 +541,7 @@ PostgreSQL documentation
|
|||||||
indicates <type>double precision</type>. Many of these functions
|
indicates <type>double precision</type>. Many of these functions
|
||||||
are provided in multiple forms with different argument types.
|
are provided in multiple forms with different argument types.
|
||||||
Except where noted, any given form of a function returns the same
|
Except where noted, any given form of a function returns the same
|
||||||
datatype as its argument.
|
data type as its argument.
|
||||||
The functions working with <type>double precision</type> data are mostly
|
The functions working with <type>double precision</type> data are mostly
|
||||||
implemented on top of the host system's C library; accuracy and behavior in
|
implemented on top of the host system's C library; accuracy and behavior in
|
||||||
boundary cases may therefore vary depending on the host system.
|
boundary cases may therefore vary depending on the host system.
|
||||||
@ -3182,7 +3182,7 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
|
|||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry> <literal>\f</> </entry>
|
<entry> <literal>\f</> </entry>
|
||||||
<entry> formfeed, as in C </entry>
|
<entry> form feed, as in C </entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -4869,7 +4869,7 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
|
|||||||
</table>
|
</table>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In addition to these functions, the SQL <literal>OVERLAPS</> keyword is
|
In addition to these functions, the SQL <literal>OVERLAPS</> operator is
|
||||||
supported:
|
supported:
|
||||||
<synopsis>
|
<synopsis>
|
||||||
( <replaceable>start1</replaceable>, <replaceable>end1</replaceable> ) OVERLAPS ( <replaceable>start2</replaceable>, <replaceable>end2</replaceable> )
|
( <replaceable>start1</replaceable>, <replaceable>end1</replaceable> ) OVERLAPS ( <replaceable>start2</replaceable>, <replaceable>end2</replaceable> )
|
||||||
@ -4877,8 +4877,8 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
|
|||||||
</synopsis>
|
</synopsis>
|
||||||
This expression yields true when two time periods (defined by their
|
This expression yields true when two time periods (defined by their
|
||||||
endpoints) overlap, false when they do not overlap. The endpoints
|
endpoints) overlap, false when they do not overlap. The endpoints
|
||||||
can be specified as pairs of dates, times, or timestamps; or as
|
can be specified as pairs of dates, times, or time stamps; or as
|
||||||
a date, time, or timestamp followed by an interval.
|
a date, time, or time stamp followed by an interval.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<screen>
|
<screen>
|
||||||
@ -5471,7 +5471,7 @@ SELECT timeofday();
|
|||||||
the intent is to allow a single transaction to have a consistent
|
the intent is to allow a single transaction to have a consistent
|
||||||
notion of the <quote>current</quote> time, so that multiple
|
notion of the <quote>current</quote> time, so that multiple
|
||||||
modifications within the same transaction bear the same
|
modifications within the same transaction bear the same
|
||||||
timestamp. <function>timeofday()</function>
|
time stamp. <function>timeofday()</function>
|
||||||
returns the wall-clock time and does advance during transactions.
|
returns the wall-clock time and does advance during transactions.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -6043,7 +6043,7 @@ SELECT TIMESTAMP 'now';
|
|||||||
<row>
|
<row>
|
||||||
<entry><literal><function>hostmask</function>(<type>inet</type>)</literal></entry>
|
<entry><literal><function>hostmask</function>(<type>inet</type>)</literal></entry>
|
||||||
<entry><type>inet</type></entry>
|
<entry><type>inet</type></entry>
|
||||||
<entry>construct hostmask for network</entry>
|
<entry>construct host mask for network</entry>
|
||||||
<entry><literal>hostmask('192.168.23.20/30')</literal></entry>
|
<entry><literal>hostmask('192.168.23.20/30')</literal></entry>
|
||||||
<entry><literal>0.0.0.3</literal></entry>
|
<entry><literal>0.0.0.3</literal></entry>
|
||||||
</row>
|
</row>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.16 2003/02/08 20:20:53 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.17 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="indexcost">
|
<chapter id="indexcost">
|
||||||
@ -39,7 +39,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.16 2003/02/08 20:2
|
|||||||
The amcostestimate function is given a list of WHERE clauses that have
|
The amcostestimate function is given a list of WHERE clauses that have
|
||||||
been determined to be usable with the index. It must return estimates
|
been determined to be usable with the index. It must return estimates
|
||||||
of the cost of accessing the index and the selectivity of the WHERE
|
of the cost of accessing the index and the selectivity of the WHERE
|
||||||
clauses (that is, the fraction of main-table tuples that will be
|
clauses (that is, the fraction of main-table rows that will be
|
||||||
retrieved during the index scan). For simple cases, nearly all the
|
retrieved during the index scan). For simple cases, nearly all the
|
||||||
work of the cost estimator can be done by calling standard routines
|
work of the cost estimator can be done by calling standard routines
|
||||||
in the optimizer; the point of having an amcostestimate function is
|
in the optimizer; the point of having an amcostestimate function is
|
||||||
@ -157,7 +157,7 @@ amcostestimate (Query *root,
|
|||||||
The index access costs should be computed in the units used by
|
The index access costs should be computed in the units used by
|
||||||
<filename>src/backend/optimizer/path/costsize.c</filename>: a sequential disk block fetch
|
<filename>src/backend/optimizer/path/costsize.c</filename>: a sequential disk block fetch
|
||||||
has cost 1.0, a nonsequential fetch has cost random_page_cost, and
|
has cost 1.0, a nonsequential fetch has cost random_page_cost, and
|
||||||
the cost of processing one index tuple should usually be taken as
|
the cost of processing one index row should usually be taken as
|
||||||
cpu_index_tuple_cost (which is a user-adjustable optimizer parameter).
|
cpu_index_tuple_cost (which is a user-adjustable optimizer parameter).
|
||||||
In addition, an appropriate multiple of cpu_operator_cost should be charged
|
In addition, an appropriate multiple of cpu_operator_cost should be charged
|
||||||
for any comparison operators invoked during index processing (especially
|
for any comparison operators invoked during index processing (especially
|
||||||
@ -167,27 +167,27 @@ amcostestimate (Query *root,
|
|||||||
<para>
|
<para>
|
||||||
The access costs should include all disk and CPU costs associated with
|
The access costs should include all disk and CPU costs associated with
|
||||||
scanning the index itself, but NOT the costs of retrieving or processing
|
scanning the index itself, but NOT the costs of retrieving or processing
|
||||||
the main-table tuples that are identified by the index.
|
the main-table rows that are identified by the index.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <quote>start-up cost</quote> is the part of the total scan cost that must be expended
|
The <quote>start-up cost</quote> is the part of the total scan cost that must be expended
|
||||||
before we can begin to fetch the first tuple. For most indexes this can
|
before we can begin to fetch the first row. For most indexes this can
|
||||||
be taken as zero, but an index type with a high start-up cost might want
|
be taken as zero, but an index type with a high start-up cost might want
|
||||||
to set it nonzero.
|
to set it nonzero.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The indexSelectivity should be set to the estimated fraction of the main
|
The indexSelectivity should be set to the estimated fraction of the main
|
||||||
table tuples that will be retrieved during the index scan. In the case
|
table rows that will be retrieved during the index scan. In the case
|
||||||
of a lossy index, this will typically be higher than the fraction of
|
of a lossy index, this will typically be higher than the fraction of
|
||||||
tuples that actually pass the given qual conditions.
|
rows that actually pass the given qual conditions.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The indexCorrelation should be set to the correlation (ranging between
|
The indexCorrelation should be set to the correlation (ranging between
|
||||||
-1.0 and 1.0) between the index order and the table order. This is used
|
-1.0 and 1.0) between the index order and the table order. This is used
|
||||||
to adjust the estimate for the cost of fetching tuples from the main
|
to adjust the estimate for the cost of fetching rows from the main
|
||||||
table.
|
table.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -199,7 +199,7 @@ amcostestimate (Query *root,
|
|||||||
|
|
||||||
<step>
|
<step>
|
||||||
<para>
|
<para>
|
||||||
Estimate and return the fraction of main-table tuples that will be visited
|
Estimate and return the fraction of main-table rows that will be visited
|
||||||
based on the given qual conditions. In the absence of any index-type-specific
|
based on the given qual conditions. In the absence of any index-type-specific
|
||||||
knowledge, use the standard optimizer function <function>clauselist_selectivity()</function>:
|
knowledge, use the standard optimizer function <function>clauselist_selectivity()</function>:
|
||||||
|
|
||||||
@ -212,10 +212,10 @@ amcostestimate (Query *root,
|
|||||||
|
|
||||||
<step>
|
<step>
|
||||||
<para>
|
<para>
|
||||||
Estimate the number of index tuples that will be visited during the
|
Estimate the number of index rows that will be visited during the
|
||||||
scan. For many index types this is the same as indexSelectivity times
|
scan. For many index types this is the same as indexSelectivity times
|
||||||
the number of tuples in the index, but it might be more. (Note that the
|
the number of rows in the index, but it might be more. (Note that the
|
||||||
index's size in pages and tuples is available from the IndexOptInfo struct.)
|
index's size in pages and rows is available from the IndexOptInfo struct.)
|
||||||
</para>
|
</para>
|
||||||
</step>
|
</step>
|
||||||
|
|
||||||
@ -234,7 +234,7 @@ amcostestimate (Query *root,
|
|||||||
/*
|
/*
|
||||||
* Our generic assumption is that the index pages will be read
|
* Our generic assumption is that the index pages will be read
|
||||||
* sequentially, so they have cost 1.0 each, not random_page_cost.
|
* sequentially, so they have cost 1.0 each, not random_page_cost.
|
||||||
* Also, we charge for evaluation of the indexquals at each index tuple.
|
* Also, we charge for evaluation of the indexquals at each index row.
|
||||||
* All the costs are assumed to be paid incrementally during the scan.
|
* All the costs are assumed to be paid incrementally during the scan.
|
||||||
*/
|
*/
|
||||||
cost_qual_eval(&index_qual_cost, indexQuals);
|
cost_qual_eval(&index_qual_cost, indexQuals);
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.174 2003/10/29 13:42:55 momjian Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.175 2003/11/01 01:56:29 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="installation">
|
<chapter id="installation">
|
||||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||||
@ -915,8 +915,9 @@ JAVACMD=$JAVA_HOME/bin/java
|
|||||||
<term><option>--enable-thread-safety</option></term>
|
<term><option>--enable-thread-safety</option></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Allow separate libpq and ecpg threads to safely control their
|
Allow separate threads in <application>libpq</application>
|
||||||
private connection handles.
|
and <application>ECPG</application> programs to safely
|
||||||
|
control their private connection handles.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.49 2003/09/20 20:12:05 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.50 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="jdbc">
|
<chapter id="jdbc">
|
||||||
@ -572,7 +572,7 @@ st.close();
|
|||||||
<sect1 id="jdbc-callproc">
|
<sect1 id="jdbc-callproc">
|
||||||
<title>Calling Stored Functions</title>
|
<title>Calling Stored Functions</title>
|
||||||
|
|
||||||
<para><productname>PostgreSQL's</productname> jdbc driver fully
|
<para><productname>PostgreSQL's</productname> JDBC driver fully
|
||||||
supports calling <productname>PostgreSQL</productname> stored
|
supports calling <productname>PostgreSQL</productname> stored
|
||||||
functions.</para>
|
functions.</para>
|
||||||
|
|
||||||
@ -636,7 +636,7 @@ upperProc.close();
|
|||||||
|
|
||||||
<para>When calling a function that returns
|
<para>When calling a function that returns
|
||||||
a <type>refcursor</type> you must cast the return type
|
a <type>refcursor</type> you must cast the return type
|
||||||
of getObject to
|
of <function>getObject</function> to
|
||||||
a <classname>ResultSet</classname></para>
|
a <classname>ResultSet</classname></para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -953,7 +953,7 @@ ps.close();
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname> is an extensible database
|
<productname>PostgreSQL</productname> is an extensible database
|
||||||
system. You can add your own functions to the backend, which can
|
system. You can add your own functions to the server, which can
|
||||||
then be called from queries, or even add your own data types. As
|
then be called from queries, or even add your own data types. As
|
||||||
these are facilities unique to <productname>PostgreSQL</productname>,
|
these are facilities unique to <productname>PostgreSQL</productname>,
|
||||||
we support them from Java, with a set of extension
|
we support them from Java, with a set of extension
|
||||||
@ -999,7 +999,7 @@ public class PGConnection
|
|||||||
public Fastpath getFastpathAPI() throws SQLException
|
public Fastpath getFastpathAPI() throws SQLException
|
||||||
</synopsis>
|
</synopsis>
|
||||||
<para>
|
<para>
|
||||||
This returns the Fastpath <acronym>API</acronym> for the
|
This returns the fast-path <acronym>API</acronym> for the
|
||||||
current connection. It is primarily used by the Large Object
|
current connection. It is primarily used by the Large Object
|
||||||
<acronym>API</acronym>.
|
<acronym>API</acronym>.
|
||||||
</para>
|
</para>
|
||||||
@ -1017,15 +1017,15 @@ Fastpath fp = ((org.postgresql.PGConnection)myconn).getFastpathAPI();
|
|||||||
<formalpara>
|
<formalpara>
|
||||||
<title>Returns:</title>
|
<title>Returns:</title>
|
||||||
<para>
|
<para>
|
||||||
Fastpath object allowing access to functions on the
|
<classname>Fastpath</> object allowing access to functions on the
|
||||||
<productname>PostgreSQL</productname> backend.
|
<productname>PostgreSQL</productname> server.
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
|
|
||||||
<formalpara>
|
<formalpara>
|
||||||
<title>Throws:</title>
|
<title>Throws:</title>
|
||||||
<para>
|
<para>
|
||||||
<classname>SQLException</> by Fastpath when initializing for first time
|
<classname>SQLException</> by <classname>Fastpath</> when initializing for first time
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -1110,7 +1110,7 @@ java.lang.Object
|
|||||||
<para>
|
<para>
|
||||||
<classname>Fastpath</classname> is an <acronym>API</acronym> that
|
<classname>Fastpath</classname> is an <acronym>API</acronym> that
|
||||||
exists within the <application>libpq</application> C interface, and allows a client machine
|
exists within the <application>libpq</application> C interface, and allows a client machine
|
||||||
to execute a function on the database backend. Most client code
|
to execute a function on the database server. Most client code
|
||||||
will not need to use this method, but it is provided because the
|
will not need to use this method, but it is provided because the
|
||||||
Large Object <acronym>API</acronym> uses it.
|
Large Object <acronym>API</acronym> uses it.
|
||||||
</para>
|
</para>
|
||||||
@ -1134,7 +1134,7 @@ Fastpath fp = ((org.postgresql.PGConnection)conn).getFastpathAPI();
|
|||||||
the <function>getFastpathAPI()</function> is an extension method,
|
the <function>getFastpathAPI()</function> is an extension method,
|
||||||
not part of <acronym>JDBC</acronym>. Once you have a
|
not part of <acronym>JDBC</acronym>. Once you have a
|
||||||
<classname>Fastpath</classname> instance, you can use the
|
<classname>Fastpath</classname> instance, you can use the
|
||||||
<function>fastpath()</function> methods to execute a backend
|
<function>fastpath()</function> methods to execute a server
|
||||||
function.
|
function.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -1156,7 +1156,7 @@ public Object fastpath(int fnid,
|
|||||||
FastpathArg args[]) throws SQLException
|
FastpathArg args[]) throws SQLException
|
||||||
</synopsis>
|
</synopsis>
|
||||||
<para>
|
<para>
|
||||||
Send a function call to the <productname>PostgreSQL</productname> backend.
|
Send a function call to the <productname>PostgreSQL</productname> server.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<formalpara>
|
<formalpara>
|
||||||
@ -1166,7 +1166,7 @@ public Object fastpath(int fnid,
|
|||||||
<parameter>resulttype</> - True if the result is an integer, false
|
<parameter>resulttype</> - True if the result is an integer, false
|
||||||
for
|
for
|
||||||
other results
|
other results
|
||||||
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fastpath
|
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fast-path call
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
|
|
||||||
@ -1186,7 +1186,7 @@ public Object fastpath(String name,
|
|||||||
FastpathArg args[]) throws SQLException
|
FastpathArg args[]) throws SQLException
|
||||||
</synopsis>
|
</synopsis>
|
||||||
<para>
|
<para>
|
||||||
Send a function call to the <productname>PostgreSQL</productname> backend by name.
|
Send a function call to the <productname>PostgreSQL</productname> server by name.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
@ -1194,7 +1194,7 @@ public Object fastpath(String name,
|
|||||||
The mapping for the procedure name to function id needs to
|
The mapping for the procedure name to function id needs to
|
||||||
exist, usually to an earlier call to <function>addfunction()</function>. This is
|
exist, usually to an earlier call to <function>addfunction()</function>. This is
|
||||||
the preferred method to call, as function id's can/may change
|
the preferred method to call, as function id's can/may change
|
||||||
between versions of the backend. For an example of how this
|
between versions of the server. For an example of how this
|
||||||
works, refer to org.postgresql.LargeObject
|
works, refer to org.postgresql.LargeObject
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
@ -1206,7 +1206,7 @@ public Object fastpath(String name,
|
|||||||
<parameter>resulttype</> - True if the result is an integer, false
|
<parameter>resulttype</> - True if the result is an integer, false
|
||||||
for
|
for
|
||||||
other results
|
other results
|
||||||
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fastpath
|
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fast-path call
|
||||||
</para>
|
</para>
|
||||||
</formalpara>
|
</formalpara>
|
||||||
|
|
||||||
@ -1381,7 +1381,7 @@ java.lang.Object
|
|||||||
</synopsis>
|
</synopsis>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Each fastpath call requires an array of arguments, the number and
|
Each fast-path call requires an array of arguments, the number and
|
||||||
type dependent on the function being called. This class
|
type dependent on the function being called. This class
|
||||||
implements methods needed to provide this capability.
|
implements methods needed to provide this capability.
|
||||||
</para>
|
</para>
|
||||||
@ -1700,7 +1700,7 @@ java.lang.Object
|
|||||||
Cloneable
|
Cloneable
|
||||||
|
|
||||||
This implements a line consisting of two points. Currently line is
|
This implements a line consisting of two points. Currently line is
|
||||||
not yet implemented in the backend, but this class ensures that when
|
not yet implemented in the server, but this class ensures that when
|
||||||
it's done were ready for it.
|
it's done were ready for it.
|
||||||
|
|
||||||
Variables
|
Variables
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.140 2003/10/17 18:57:01 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.141 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="libpq">
|
<chapter id="libpq">
|
||||||
@ -92,7 +92,7 @@ PGconn *PQconnectdb(const char *conninfo);
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The currently recognized parameter keywords are:
|
The currently recognized parameter key words are:
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
@ -307,7 +307,7 @@ PGconn *PQsetdbLogin(const char *pghost,
|
|||||||
<para>
|
<para>
|
||||||
This is the predecessor of <function>PQconnectdb</function> with a fixed
|
This is the predecessor of <function>PQconnectdb</function> with a fixed
|
||||||
set of parameters. It has the same functionality except that the
|
set of parameters. It has the same functionality except that the
|
||||||
missing parameters will always take on default values. Write NULL or an
|
missing parameters will always take on default values. Write <symbol>NULL</symbol> or an
|
||||||
empty string for any one of the fixed parameters that is to be defaulted.
|
empty string for any one of the fixed parameters that is to be defaulted.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -849,7 +849,7 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
|
|||||||
Certain parameter values are reported by the server automatically at
|
Certain parameter values are reported by the server automatically at
|
||||||
connection startup or whenever their values change.
|
connection startup or whenever their values change.
|
||||||
<function>PQparameterStatus</> can be used to interrogate these settings.
|
<function>PQparameterStatus</> can be used to interrogate these settings.
|
||||||
It returns the current value of a parameter if known, or NULL if the parameter
|
It returns the current value of a parameter if known, or <symbol>NULL</symbol> if the parameter
|
||||||
is not known.
|
is not known.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -890,7 +890,7 @@ or zero (connection bad). This will not change after connection
|
|||||||
startup is complete, but it could theoretically change during a reset.
|
startup is complete, but it could theoretically change during a reset.
|
||||||
The 3.0 protocol will normally be used when communicating with
|
The 3.0 protocol will normally be used when communicating with
|
||||||
<productname>PostgreSQL</> 7.4 or later servers; pre-7.4 servers support
|
<productname>PostgreSQL</> 7.4 or later servers; pre-7.4 servers support
|
||||||
only protocol 2.0. (Protocol 1.0 is obsolete and not supported by libpq.)
|
only protocol 2.0. (Protocol 1.0 is obsolete and not supported by <application>libpq</application>.)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1071,23 +1071,23 @@ as <literal>$1</>, <literal>$2</>, etc.
|
|||||||
<parameter>nParams</> is the number of parameters supplied; it is the length
|
<parameter>nParams</> is the number of parameters supplied; it is the length
|
||||||
of the arrays <parameter>paramTypes[]</>, <parameter>paramValues[]</>,
|
of the arrays <parameter>paramTypes[]</>, <parameter>paramValues[]</>,
|
||||||
<parameter>paramLengths[]</>, and <parameter>paramFormats[]</>. (The
|
<parameter>paramLengths[]</>, and <parameter>paramFormats[]</>. (The
|
||||||
array pointers may be NULL when <parameter>nParams</> is zero.)
|
array pointers may be <symbol>NULL</symbol> when <parameter>nParams</> is zero.)
|
||||||
<parameter>paramTypes[]</> specifies, by OID, the datatypes to be assigned to
|
<parameter>paramTypes[]</> specifies, by OID, the data types to be assigned to
|
||||||
the parameter symbols. If <parameter>paramTypes</> is NULL, or any particular
|
the parameter symbols. If <parameter>paramTypes</> is <symbol>NULL</symbol>, or any particular
|
||||||
element in the array is zero, the backend assigns a datatype to the parameter
|
element in the array is zero, the server assigns a data type to the parameter
|
||||||
symbol in the same way it would do for an untyped literal string.
|
symbol in the same way it would do for an untyped literal string.
|
||||||
<parameter>paramValues[]</> specifies the actual values of the parameters.
|
<parameter>paramValues[]</> specifies the actual values of the parameters.
|
||||||
A NULL pointer in this array means the corresponding parameter is NULL;
|
A null pointer in this array means the corresponding parameter is null;
|
||||||
otherwise the pointer points to a zero-terminated text string (for text
|
otherwise the pointer points to a zero-terminated text string (for text
|
||||||
format) or binary data in the format expected by the backend (for binary
|
format) or binary data in the format expected by the server (for binary
|
||||||
format).
|
format).
|
||||||
<parameter>paramLengths[]</> specifies the actual data lengths of
|
<parameter>paramLengths[]</> specifies the actual data lengths of
|
||||||
binary-format parameters. It is ignored for NULL parameters and text-format
|
binary-format parameters. It is ignored for null parameters and text-format
|
||||||
parameters. The array pointer may be NULL when there are no binary
|
parameters. The array pointer may be null when there are no binary
|
||||||
parameters.
|
parameters.
|
||||||
<parameter>paramFormats[]</> specifies whether parameters are text (put a zero
|
<parameter>paramFormats[]</> specifies whether parameters are text (put a zero
|
||||||
in the array) or binary (put a one in the array). If the array pointer is
|
in the array) or binary (put a one in the array). If the array pointer is
|
||||||
NULL then all parameters are presumed to be text.
|
null then all parameters are presumed to be text.
|
||||||
<parameter>resultFormat</> is zero to obtain results in text format, or one to
|
<parameter>resultFormat</> is zero to obtain results in text format, or one to
|
||||||
obtain results in binary format. (There is not currently a provision to
|
obtain results in binary format. (There is not currently a provision to
|
||||||
obtain different result columns in different formats, although that is
|
obtain different result columns in different formats, although that is
|
||||||
@ -1544,7 +1544,7 @@ char *PQfname(const PGresult *res,
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
NULL is returned if the column number is out of range.
|
<symbol>NULL</symbol> is returned if the column number is out of range.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1761,15 +1761,15 @@ char* PQgetvalue(const PGresult *res,
|
|||||||
For data in text format, the value returned by <function>PQgetvalue</function>
|
For data in text format, the value returned by <function>PQgetvalue</function>
|
||||||
is a null-terminated character string representation
|
is a null-terminated character string representation
|
||||||
of the field value. For data in binary format, the value is in the binary
|
of the field value. For data in binary format, the value is in the binary
|
||||||
representation determined by the datatype's <function>typsend</> and
|
representation determined by the data type's <function>typsend</> and
|
||||||
<function>typreceive</> functions. (The value is actually followed by
|
<function>typreceive</> functions. (The value is actually followed by
|
||||||
a zero byte in this case too, but that is not ordinarily useful, since
|
a zero byte in this case too, but that is not ordinarily useful, since
|
||||||
the value is likely to contain embedded nulls.)
|
the value is likely to contain embedded nulls.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
An empty string is returned if the field value is NULL. See
|
An empty string is returned if the field value is null. See
|
||||||
<function>PQgetisnull</> to distinguish NULLs from empty-string values.
|
<function>PQgetisnull</> to distinguish null values from empty-string values.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -2123,7 +2123,7 @@ void PQfreemem(void *ptr);
|
|||||||
<function>PQunescapeBytea</function>,
|
<function>PQunescapeBytea</function>,
|
||||||
and <function>PQnotifies</function>.
|
and <function>PQnotifies</function>.
|
||||||
It is needed by Win32, which can not free memory across
|
It is needed by Win32, which can not free memory across
|
||||||
DLL's, unless multithreaded DLL's (/MD in VC6) are used.
|
DLLs, unless multithreaded DLLs (<option>/MD</option> in VC6) are used.
|
||||||
On other platforms it is the same as <function>free()</>.
|
On other platforms it is the same as <function>free()</>.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -2547,13 +2547,13 @@ typedef struct {
|
|||||||
parameters to be passed to the function; they must match the declared
|
parameters to be passed to the function; they must match the declared
|
||||||
function argument list. When the <parameter>isint</> field of a
|
function argument list. When the <parameter>isint</> field of a
|
||||||
parameter
|
parameter
|
||||||
struct is true,
|
structure is true,
|
||||||
the <parameter>u.integer</> value is sent to the server as an integer
|
the <parameter>u.integer</> value is sent to the server as an integer
|
||||||
of the indicated length (this must be 1, 2, or 4 bytes); proper
|
of the indicated length (this must be 1, 2, or 4 bytes); proper
|
||||||
byte-swapping occurs. When <parameter>isint</> is false, the
|
byte-swapping occurs. When <parameter>isint</> is false, the
|
||||||
indicated number of bytes at <parameter>*u.ptr</> are sent with no
|
indicated number of bytes at <parameter>*u.ptr</> are sent with no
|
||||||
processing; the data must be in the format expected by the server for
|
processing; the data must be in the format expected by the server for
|
||||||
binary transmission of the function's argument datatype.
|
binary transmission of the function's argument data type.
|
||||||
<parameter>result_buf</parameter> is the buffer in which
|
<parameter>result_buf</parameter> is the buffer in which
|
||||||
to place the return value. The caller must have allocated
|
to place the return value. The caller must have allocated
|
||||||
sufficient space to store the return value. (There is no check!)
|
sufficient space to store the return value. (There is no check!)
|
||||||
@ -2577,7 +2577,7 @@ caller is responsible for freeing the <structname>PGresult</structname> with
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Note that it is not possible to handle NULL arguments, NULL results, nor
|
Note that it is not possible to handle null arguments, null results, nor
|
||||||
set-valued results when using this interface.
|
set-valued results when using this interface.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -2646,8 +2646,8 @@ do not represent separate allocations.
|
|||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
In <productname>PostgreSQL</productname> 6.4 and later,
|
In <productname>PostgreSQL</productname> 6.4 and later,
|
||||||
the <structfield>be_pid</structfield> is that of the notifying backend process,
|
the <structfield>be_pid</structfield> is that of the notifying server process,
|
||||||
whereas in earlier versions it was always the <acronym>PID</acronym> of your own backend process.
|
whereas in earlier versions it was always the <acronym>PID</acronym> of your own server process.
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -2724,7 +2724,7 @@ if any notifications came in during the processing of the command.
|
|||||||
<function>PQexec</function> in a string that could contain additional
|
<function>PQexec</function> in a string that could contain additional
|
||||||
commands, the application must continue fetching results via
|
commands, the application must continue fetching results via
|
||||||
<function>PQgetResult</> after completing the <command>COPY</command>
|
<function>PQgetResult</> after completing the <command>COPY</command>
|
||||||
sequence. Only when <function>PQgetResult</> returns NULL is it certain
|
sequence. Only when <function>PQgetResult</> returns <symbol>NULL</symbol> is it certain
|
||||||
that the <function>PQexec</function> command string is done and it is
|
that the <function>PQexec</function> command string is done and it is
|
||||||
safe to issue more commands.
|
safe to issue more commands.
|
||||||
</para>
|
</para>
|
||||||
@ -2816,15 +2816,15 @@ int PQputCopyData(PGconn *conn,
|
|||||||
Transmits the COPY data in the specified <parameter>buffer</>, of length
|
Transmits the COPY data in the specified <parameter>buffer</>, of length
|
||||||
<parameter>nbytes</>, to the server. The result is 1 if the data was sent,
|
<parameter>nbytes</>, to the server. The result is 1 if the data was sent,
|
||||||
zero if it was not sent because the attempt would block (this case is only
|
zero if it was not sent because the attempt would block (this case is only
|
||||||
possible if the connection is in nonblock mode), or -1 if an error occurred.
|
possible if the connection is in nonblocking mode), or -1 if an error occurred.
|
||||||
(Use <function>PQerrorMessage</function> to retrieve details if the return
|
(Use <function>PQerrorMessage</function> to retrieve details if the return
|
||||||
value is -1. If the value is zero, wait for write-ready and try again.)
|
value is -1. If the value is zero, wait for write-ready and try again.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The application may divide the COPY datastream into bufferloads of any
|
The application may divide the <command>COPY</command> data stream into buffer loads of any
|
||||||
convenient size. Bufferload boundaries have no semantic significance when
|
convenient size. Buffer-load boundaries have no semantic significance when
|
||||||
sending. The contents of the datastream must match the data format expected
|
sending. The contents of the data stream must match the data format expected
|
||||||
by the <command>COPY</> command; see
|
by the <command>COPY</> command; see
|
||||||
<xref linkend="sql-copy" endterm="sql-copy-title"> for details.
|
<xref linkend="sql-copy" endterm="sql-copy-title"> for details.
|
||||||
</para>
|
</para>
|
||||||
@ -2844,7 +2844,7 @@ int PQputCopyEnd(PGconn *conn,
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Ends the <literal>COPY_IN</> operation successfully if <parameter>errormsg</>
|
Ends the <literal>COPY_IN</> operation successfully if <parameter>errormsg</>
|
||||||
is NULL. If <parameter>errormsg</> is not NULL then the <command>COPY</>
|
is <symbol>NULL</symbol>. If <parameter>errormsg</> is not <symbol>NULL</symbol> then the <command>COPY</>
|
||||||
is forced to fail, with the string pointed to by <parameter>errormsg</>
|
is forced to fail, with the string pointed to by <parameter>errormsg</>
|
||||||
used as the error message. (One should not assume that this exact error
|
used as the error message. (One should not assume that this exact error
|
||||||
message will come back from the server, however, as the server might have
|
message will come back from the server, however, as the server might have
|
||||||
@ -2855,7 +2855,7 @@ option to force failure does not work when using pre-3.0-protocol connections.)
|
|||||||
<para>
|
<para>
|
||||||
The result is 1 if the termination data was sent,
|
The result is 1 if the termination data was sent,
|
||||||
zero if it was not sent because the attempt would block (this case is only
|
zero if it was not sent because the attempt would block (this case is only
|
||||||
possible if the connection is in nonblock mode), or -1 if an error occurred.
|
possible if the connection is in nonblocking mode), or -1 if an error occurred.
|
||||||
(Use <function>PQerrorMessage</function> to retrieve details if the return
|
(Use <function>PQerrorMessage</function> to retrieve details if the return
|
||||||
value is -1. If the value is zero, wait for write-ready and try again.)
|
value is -1. If the value is zero, wait for write-ready and try again.)
|
||||||
</para>
|
</para>
|
||||||
@ -2900,9 +2900,9 @@ Attempts to obtain another row of data from the server during a COPY.
|
|||||||
Data is always returned one data row at a time; if only a partial row
|
Data is always returned one data row at a time; if only a partial row
|
||||||
is available, it is not returned. Successful return of a data row
|
is available, it is not returned. Successful return of a data row
|
||||||
involves allocating a chunk of memory to hold the data. The
|
involves allocating a chunk of memory to hold the data. The
|
||||||
<parameter>buffer</> parameter must be non-NULL. <parameter>*buffer</>
|
<parameter>buffer</> parameter must be non-<symbol>NULL</symbol>. <parameter>*buffer</>
|
||||||
is set to point to the allocated memory, or to NULL in cases where no
|
is set to point to the allocated memory, or to <symbol>NULL</symbol> in cases where no
|
||||||
buffer is returned. A non-NULL result buffer must be freed using
|
buffer is returned. A non-<symbol>NULL</symbol> result buffer must be freed using
|
||||||
<function>PQfreemem</> when no longer needed.
|
<function>PQfreemem</> when no longer needed.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -3053,7 +3053,7 @@ int PQputline(PGconn *conn,
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The COPY datastream sent by a series of calls to
|
The <command>COPY</command> data stream sent by a series of calls to
|
||||||
<function>PQputline</function> has the same format as that returned by
|
<function>PQputline</function> has the same format as that returned by
|
||||||
<function>PQgetlineAsync</function>, except that applications are not
|
<function>PQgetlineAsync</function>, except that applications are not
|
||||||
obliged to send exactly one data row per <function>PQputline</function>
|
obliged to send exactly one data row per <function>PQputline</function>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.30 2003/08/31 17:32:19 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.31 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="largeObjects">
|
<chapter id="largeObjects">
|
||||||
@ -324,10 +324,10 @@ SELECT lo_export(image.raster, '/tmp/motd') FROM image
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These functions read and write files in the server's filesystem, using the
|
These functions read and write files in the server's file system, using the
|
||||||
permissions of the database's owning user. Therefore, their use is restricted
|
permissions of the database's owning user. Therefore, their use is restricted
|
||||||
to superusers. (In contrast, the client-side import and export functions
|
to superusers. (In contrast, the client-side import and export functions
|
||||||
read and write files in the client's filesystem, using the permissions of
|
read and write files in the client's file system, using the permissions of
|
||||||
the client program. Their use is not restricted.)
|
the client program. Their use is not restricted.)
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.27 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="maintenance">
|
<chapter id="maintenance">
|
||||||
@ -101,13 +101,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
|
|||||||
<para>
|
<para>
|
||||||
In normal <productname>PostgreSQL</productname> operation, an
|
In normal <productname>PostgreSQL</productname> operation, an
|
||||||
<command>UPDATE</> or <command>DELETE</> of a row does not
|
<command>UPDATE</> or <command>DELETE</> of a row does not
|
||||||
immediately remove the old <firstterm>tuple</> (version of the row).
|
immediately remove the old version of the row.
|
||||||
This approach is necessary to gain the benefits of multiversion
|
This approach is necessary to gain the benefits of multiversion
|
||||||
concurrency control (see <xref linkend="mvcc">): the tuple
|
concurrency control (see <xref linkend="mvcc">): the row version
|
||||||
must not be deleted while it is still potentially visible to other
|
must not be deleted while it is still potentially visible to other
|
||||||
transactions. But eventually, an outdated or deleted tuple is no
|
transactions. But eventually, an outdated or deleted row version is no
|
||||||
longer of interest to any transaction. The space it occupies must be
|
longer of interest to any transaction. The space it occupies must be
|
||||||
reclaimed for reuse by new tuples, to avoid infinite growth of disk
|
reclaimed for reuse by new rows, to avoid infinite growth of disk
|
||||||
space requirements. This is done by running <command>VACUUM</>.
|
space requirements. This is done by running <command>VACUUM</>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -125,7 +125,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
|
|||||||
<para>
|
<para>
|
||||||
The standard form of <command>VACUUM</> is best used with the goal of
|
The standard form of <command>VACUUM</> is best used with the goal of
|
||||||
maintaining a fairly level steady-state usage of disk space. The standard
|
maintaining a fairly level steady-state usage of disk space. The standard
|
||||||
form finds old tuples and makes their space available for re-use within
|
form finds old row versions and makes their space available for re-use within
|
||||||
the table, but it does not try very hard to shorten the table file and
|
the table, but it does not try very hard to shorten the table file and
|
||||||
return disk space to the operating system. If you need to return disk
|
return disk space to the operating system. If you need to return disk
|
||||||
space to the operating system you can use <command>VACUUM FULL</> ---
|
space to the operating system you can use <command>VACUUM FULL</> ---
|
||||||
@ -147,7 +147,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>VACUUM FULL</> is recommended for cases where you know you have
|
<command>VACUUM FULL</> is recommended for cases where you know you have
|
||||||
deleted the majority of tuples in a table, so that the steady-state size
|
deleted the majority of rows in a table, so that the steady-state size
|
||||||
of the table can be shrunk substantially with <command>VACUUM FULL</>'s
|
of the table can be shrunk substantially with <command>VACUUM FULL</>'s
|
||||||
more aggressive approach.
|
more aggressive approach.
|
||||||
</para>
|
</para>
|
||||||
@ -242,7 +242,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
|
|||||||
<para>
|
<para>
|
||||||
<productname>PostgreSQL</productname>'s MVCC transaction semantics
|
<productname>PostgreSQL</productname>'s MVCC transaction semantics
|
||||||
depend on being able to compare transaction ID (<acronym>XID</>)
|
depend on being able to compare transaction ID (<acronym>XID</>)
|
||||||
numbers: a tuple with an insertion XID greater than the current
|
numbers: a row version with an insertion XID greater than the current
|
||||||
transaction's XID is <quote>in the future</> and should not be visible
|
transaction's XID is <quote>in the future</> and should not be visible
|
||||||
to the current transaction. But since transaction IDs have limited size
|
to the current transaction. But since transaction IDs have limited size
|
||||||
(32 bits at this writing) a cluster that runs for a long time (more
|
(32 bits at this writing) a cluster that runs for a long time (more
|
||||||
@ -283,29 +283,29 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
|
|||||||
that for every normal XID, there are two billion XIDs that are
|
that for every normal XID, there are two billion XIDs that are
|
||||||
<quote>older</> and two billion that are <quote>newer</>; another
|
<quote>older</> and two billion that are <quote>newer</>; another
|
||||||
way to say it is that the normal XID space is circular with no
|
way to say it is that the normal XID space is circular with no
|
||||||
endpoint. Therefore, once a tuple has been created with a particular
|
endpoint. Therefore, once a row version has been created with a particular
|
||||||
normal XID, the tuple will appear to be <quote>in the past</> for
|
normal XID, the row version will appear to be <quote>in the past</> for
|
||||||
the next two billion transactions, no matter which normal XID we are
|
the next two billion transactions, no matter which normal XID we are
|
||||||
talking about. If the tuple still exists after more than two billion
|
talking about. If the row version still exists after more than two billion
|
||||||
transactions, it will suddenly appear to be in the future. To
|
transactions, it will suddenly appear to be in the future. To
|
||||||
prevent data loss, old tuples must be reassigned the XID
|
prevent data loss, old row versions must be reassigned the XID
|
||||||
<literal>FrozenXID</> sometime before they reach the
|
<literal>FrozenXID</> sometime before they reach the
|
||||||
two-billion-transactions-old mark. Once they are assigned this
|
two-billion-transactions-old mark. Once they are assigned this
|
||||||
special XID, they will appear to be <quote>in the past</> to all
|
special XID, they will appear to be <quote>in the past</> to all
|
||||||
normal transactions regardless of wraparound issues, and so such
|
normal transactions regardless of wraparound issues, and so such
|
||||||
tuples will be good until deleted, no matter how long that is. This
|
row versions will be good until deleted, no matter how long that is. This
|
||||||
reassignment of XID is handled by <command>VACUUM</>.
|
reassignment of XID is handled by <command>VACUUM</>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>VACUUM</>'s normal policy is to reassign <literal>FrozenXID</>
|
<command>VACUUM</>'s normal policy is to reassign <literal>FrozenXID</>
|
||||||
to any tuple with a normal XID more than one billion transactions in the
|
to any row version with a normal XID more than one billion transactions in the
|
||||||
past. This policy preserves the original insertion XID until it is not
|
past. This policy preserves the original insertion XID until it is not
|
||||||
likely to be of interest anymore. (In fact, most tuples will probably
|
likely to be of interest anymore. (In fact, most row versions will probably
|
||||||
live and die without ever being <quote>frozen</>.) With this policy,
|
live and die without ever being <quote>frozen</>.) With this policy,
|
||||||
the maximum safe interval between <command>VACUUM</> runs on any table
|
the maximum safe interval between <command>VACUUM</> runs on any table
|
||||||
is exactly one billion transactions: if you wait longer, it's possible
|
is exactly one billion transactions: if you wait longer, it's possible
|
||||||
that a tuple that was not quite old enough to be reassigned last time
|
that a row version that was not quite old enough to be reassigned last time
|
||||||
is now more than two billion transactions old and has wrapped around
|
is now more than two billion transactions old and has wrapped around
|
||||||
into the future --- i.e., is lost to you. (Of course, it'll reappear
|
into the future --- i.e., is lost to you. (Of course, it'll reappear
|
||||||
after another two billion transactions, but that's no help.)
|
after another two billion transactions, but that's no help.)
|
||||||
@ -355,10 +355,10 @@ VACUUM
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>VACUUM</> with the <command>FREEZE</> option uses a more
|
<command>VACUUM</> with the <command>FREEZE</> option uses a more
|
||||||
aggressive freezing policy: tuples are frozen if they are old enough
|
aggressive freezing policy: row versions are frozen if they are old enough
|
||||||
to be considered good by all open transactions. In particular, if a
|
to be considered good by all open transactions. In particular, if a
|
||||||
<command>VACUUM FREEZE</> is performed in an otherwise-idle
|
<command>VACUUM FREEZE</> is performed in an otherwise-idle
|
||||||
database, it is guaranteed that <emphasis>all</> tuples in that
|
database, it is guaranteed that <emphasis>all</> row versions in that
|
||||||
database will be frozen. Hence, as long as the database is not
|
database will be frozen. Hence, as long as the database is not
|
||||||
modified in any way, it will not need subsequent vacuuming to avoid
|
modified in any way, it will not need subsequent vacuuming to avoid
|
||||||
transaction ID wraparound problems. This technique is used by
|
transaction ID wraparound problems. This technique is used by
|
||||||
@ -422,13 +422,16 @@ VACUUM
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The simplest production-grade approach to managing log output is to
|
The simplest production-grade approach to managing log output is to
|
||||||
send it all to <application>syslog</> and let <application>syslog</>
|
send it all to <application>syslog</> and let
|
||||||
deal with file rotation. To do this, set the configurations parameter
|
<application>syslog</> deal with file rotation. To do this, set the
|
||||||
<literal>syslog</> to 2 (to log to <application>syslog</> only) in
|
configurations parameter <literal>syslog</> to 2 (to log to
|
||||||
<filename>postgresql.conf</>. Then you can send a <literal>SIGHUP</literal>
|
<application>syslog</> only) in <filename>postgresql.conf</>. Then
|
||||||
signal to the <application>syslog</> daemon whenever you want to force it
|
you can send a <literal>SIGHUP</literal> signal to the
|
||||||
to start writing a new log file. If you want to automate log rotation,
|
<application>syslog</> daemon whenever you want to force it to
|
||||||
the logrotate program can be configured to work with log files from syslog.
|
start writing a new log file. If you want to automate log
|
||||||
|
rotation, the <application>logrotate</application> program can be
|
||||||
|
configured to work with log files from
|
||||||
|
<application>syslog</application>.
|
||||||
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.22 2003/10/17 22:38:20 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.23 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="monitoring">
|
<chapter id="monitoring">
|
||||||
@ -237,8 +237,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_all_tables</></entry>
|
<entry><structname>pg_stat_all_tables</></entry>
|
||||||
<entry>For each table in the current database, total numbers of
|
<entry>For each table in the current database, total numbers of
|
||||||
sequential and index scans, total numbers of tuples returned by
|
sequential and index scans, total numbers of rows returned by
|
||||||
each type of scan, and totals of tuple insertions, updates,
|
each type of scan, and totals of row insertions, updates,
|
||||||
and deletions.</entry>
|
and deletions.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -257,9 +257,9 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<row>
|
<row>
|
||||||
<entry><structname>pg_stat_all_indexes</></entry>
|
<entry><structname>pg_stat_all_indexes</></entry>
|
||||||
<entry>For each index in the current database, the total number
|
<entry>For each index in the current database, the total number
|
||||||
of index scans that have used that index, the number of index tuples
|
of index scans that have used that index, the number of index rows
|
||||||
read, and the number of successfully fetched heap tuples. (This may
|
read, and the number of successfully fetched heap rows. (This may
|
||||||
be less when there are index entries pointing to expired heap tuples.)
|
be less when there are index entries pointing to expired heap rows.)
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -441,8 +441,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><literal><function>pg_stat_get_tuples_returned</function>(<type>oid</type>)</literal></entry>
|
<entry><literal><function>pg_stat_get_tuples_returned</function>(<type>oid</type>)</literal></entry>
|
||||||
<entry><type>bigint</type></entry>
|
<entry><type>bigint</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of tuples read by sequential scans when argument is a table,
|
Number of rows read by sequential scans when argument is a table,
|
||||||
or number of index tuples read when argument is an index
|
or number of index rows read when argument is an index
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -450,7 +450,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><literal><function>pg_stat_get_tuples_fetched</function>(<type>oid</type>)</literal></entry>
|
<entry><literal><function>pg_stat_get_tuples_fetched</function>(<type>oid</type>)</literal></entry>
|
||||||
<entry><type>bigint</type></entry>
|
<entry><type>bigint</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of valid (unexpired) table tuples fetched by sequential scans
|
Number of valid (unexpired) table rows fetched by sequential scans
|
||||||
when argument is a table, or fetched by index scans using this index
|
when argument is a table, or fetched by index scans using this index
|
||||||
when argument is an index
|
when argument is an index
|
||||||
</entry>
|
</entry>
|
||||||
@ -460,7 +460,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><literal><function>pg_stat_get_tuples_inserted</function>(<type>oid</type>)</literal></entry>
|
<entry><literal><function>pg_stat_get_tuples_inserted</function>(<type>oid</type>)</literal></entry>
|
||||||
<entry><type>bigint</type></entry>
|
<entry><type>bigint</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of tuples inserted into table
|
Number of rows inserted into table
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -468,7 +468,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><literal><function>pg_stat_get_tuples_updated</function>(<type>oid</type>)</literal></entry>
|
<entry><literal><function>pg_stat_get_tuples_updated</function>(<type>oid</type>)</literal></entry>
|
||||||
<entry><type>bigint</type></entry>
|
<entry><type>bigint</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of tuples updated in table
|
Number of rows updated in table
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@ -476,7 +476,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
|||||||
<entry><literal><function>pg_stat_get_tuples_deleted</function>(<type>oid</type>)</literal></entry>
|
<entry><literal><function>pg_stat_get_tuples_deleted</function>(<type>oid</type>)</literal></entry>
|
||||||
<entry><type>bigint</type></entry>
|
<entry><type>bigint</type></entry>
|
||||||
<entry>
|
<entry>
|
||||||
Number of tuples deleted from table
|
Number of rows deleted from table
|
||||||
</entry>
|
</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.6 2003/05/19 21:38:23 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.7 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="nls">
|
<chapter id="nls">
|
||||||
@ -35,7 +35,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.6 2003/05/19 21:38:23 tgl Exp
|
|||||||
this is only in the unlikely event that you do not want to try out
|
this is only in the unlikely event that you do not want to try out
|
||||||
your translated messages. When you configure your source tree, be
|
your translated messages. When you configure your source tree, be
|
||||||
sure to use the <option>--enable-nls</option> option. This will
|
sure to use the <option>--enable-nls</option> option. This will
|
||||||
also check for the libintl library and the
|
also check for the <application>libintl</application> library and the
|
||||||
<filename>msgfmt</filename> program, which all end users will need
|
<filename>msgfmt</filename> program, which all end users will need
|
||||||
anyway. To try out your work, follow the applicable portions of
|
anyway. To try out your work, follow the applicable portions of
|
||||||
the installation instructions.
|
the installation instructions.
|
||||||
@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.6 2003/05/19 21:38:23 tgl Exp
|
|||||||
implementation. Later, we will try to arrange it so that if you
|
implementation. Later, we will try to arrange it so that if you
|
||||||
use a packaged source distribution, you won't need
|
use a packaged source distribution, you won't need
|
||||||
<filename>xgettext</filename>. (From CVS, you will still need
|
<filename>xgettext</filename>. (From CVS, you will still need
|
||||||
it.) GNU gettext 0.10.36 or later is currently recommended.
|
it.) <application>GNU Gettext 0.10.36</application> or later is currently recommended.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -374,7 +374,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
|
|||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>CATALOG_NAME</term>
|
<term><varname>CATALOG_NAME</varname></term>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -385,7 +385,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
|
|||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>AVAIL_LANGUAGES</term>
|
<term><varname>AVAIL_LANGUAGES</varname></term>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -395,7 +395,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
|
|||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>GETTEXT_FILES</term>
|
<term><varname>GETTEXT_FILES</varname></term>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
@ -411,7 +411,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
|
|||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>GETTEXT_TRIGGERS</term>
|
<term><varname>GETTEXT_TRIGGERS</varname></term>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/page.sgml,v 1.14 2003/09/29 18:18:35 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/page.sgml,v 1.15 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="page">
|
<chapter id="page">
|
||||||
@ -27,7 +27,7 @@ In the following explanation, a
|
|||||||
is assumed to contain 8 bits. In addition, the term
|
is assumed to contain 8 bits. In addition, the term
|
||||||
<firstterm>item</firstterm>
|
<firstterm>item</firstterm>
|
||||||
refers to an individual data value that is stored on a page. In a table,
|
refers to an individual data value that is stored on a page. In a table,
|
||||||
an item is a tuple (row); in an index, an item is an index entry.
|
an item is a row; in an index, an item is an index entry.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@ -65,7 +65,7 @@ free space pointers.</entry>
|
|||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>Free space</entry>
|
<entry>Free space</entry>
|
||||||
<entry>The unallocated space. All new tuples are allocated from here, generally from the end.</entry>
|
<entry>The unallocated space. All new rows are allocated from here, generally from the end.</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
@ -162,7 +162,7 @@ data. Empty in ordinary tables.</entry>
|
|||||||
and a version indicator. Beginning with
|
and a version indicator. Beginning with
|
||||||
<productname>PostgreSQL</productname> 7.3 the version number is 1; prior
|
<productname>PostgreSQL</productname> 7.3 the version number is 1; prior
|
||||||
releases used version number 0. (The basic page layout and header format
|
releases used version number 0. (The basic page layout and header format
|
||||||
has not changed, but the layout of heap tuple headers has.) The page size
|
has not changed, but the layout of heap row headers has.) The page size
|
||||||
is basically only present as a cross-check; there is no support for having
|
is basically only present as a cross-check; there is no support for having
|
||||||
more than one page size in an installation.
|
more than one page size in an installation.
|
||||||
</para>
|
</para>
|
||||||
@ -209,12 +209,12 @@ data. Empty in ordinary tables.</entry>
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
||||||
All table tuples are structured the same way. There is a fixed-size
|
All table rows are structured the same way. There is a fixed-size
|
||||||
header (occupying 23 bytes on most machines), followed by an optional null
|
header (occupying 23 bytes on most machines), followed by an optional null
|
||||||
bitmap, an optional object ID field, and the user data. The header is
|
bitmap, an optional object ID field, and the user data. The header is
|
||||||
detailed
|
detailed
|
||||||
in <xref linkend="heaptupleheaderdata-table">. The actual user data
|
in <xref linkend="heaptupleheaderdata-table">. The actual user data
|
||||||
(fields of the tuple) begins at the offset indicated by
|
(columns of the row) begins at the offset indicated by
|
||||||
<structfield>t_hoff</>, which must always be a multiple of the MAXALIGN
|
<structfield>t_hoff</>, which must always be a multiple of the MAXALIGN
|
||||||
distance for the platform.
|
distance for the platform.
|
||||||
The null bitmap is
|
The null bitmap is
|
||||||
@ -274,13 +274,13 @@ data. Empty in ordinary tables.</entry>
|
|||||||
<entry>t_xvac</entry>
|
<entry>t_xvac</entry>
|
||||||
<entry>TransactionId</entry>
|
<entry>TransactionId</entry>
|
||||||
<entry>4 bytes</entry>
|
<entry>4 bytes</entry>
|
||||||
<entry>XID for VACUUM operation moving tuple</entry>
|
<entry>XID for VACUUM operation moving row version</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>t_ctid</entry>
|
<entry>t_ctid</entry>
|
||||||
<entry>ItemPointerData</entry>
|
<entry>ItemPointerData</entry>
|
||||||
<entry>6 bytes</entry>
|
<entry>6 bytes</entry>
|
||||||
<entry>current TID of this or newer tuple</entry>
|
<entry>current TID of this or newer row version</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>t_natts</entry>
|
<entry>t_natts</entry>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.36 2003/10/17 22:38:20 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.37 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="performance-tips">
|
<chapter id="performance-tips">
|
||||||
@ -614,7 +614,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
|||||||
<varname>from_collapse_limit</> (so that explicit joins and subselects
|
<varname>from_collapse_limit</> (so that explicit joins and subselects
|
||||||
act similarly) or set <varname>join_collapse_limit</> to 1 (if you want
|
act similarly) or set <varname>join_collapse_limit</> to 1 (if you want
|
||||||
to control join order with explicit joins). But you might set them
|
to control join order with explicit joins). But you might set them
|
||||||
differently if you are trying to fine-tune the tradeoff between planning
|
differently if you are trying to fine-tune the trade off between planning
|
||||||
time and run time.
|
time and run time.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.27 2003/09/23 19:58:50 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.28 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="plpgsql">
|
<chapter id="plpgsql">
|
||||||
@ -180,11 +180,11 @@ END;
|
|||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 id="plpgsql-args-results">
|
<sect2 id="plpgsql-args-results">
|
||||||
<title>Supported Argument and Result Datatypes</title>
|
<title>Supported Argument and Result Data Types</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Functions written in <application>PL/pgSQL</application> can accept
|
Functions written in <application>PL/pgSQL</application> can accept
|
||||||
as arguments any scalar or array datatype supported by the server,
|
as arguments any scalar or array data type supported by the server,
|
||||||
and they can return a result of any of these types. They can also
|
and they can return a result of any of these types. They can also
|
||||||
accept or return any composite type (row type) specified by name.
|
accept or return any composite type (row type) specified by name.
|
||||||
It is also possible to declare a <application>PL/pgSQL</application>
|
It is also possible to declare a <application>PL/pgSQL</application>
|
||||||
@ -197,14 +197,14 @@ END;
|
|||||||
<application>PL/pgSQL</> functions may also be declared to accept
|
<application>PL/pgSQL</> functions may also be declared to accept
|
||||||
and return the <quote>polymorphic</> types
|
and return the <quote>polymorphic</> types
|
||||||
<type>anyelement</type> and <type>anyarray</type>. The actual
|
<type>anyelement</type> and <type>anyarray</type>. The actual
|
||||||
datatypes handled by a polymorphic function can vary from call to
|
data types handled by a polymorphic function can vary from call to
|
||||||
call, as discussed in <xref linkend="extend-types-polymorphic">.
|
call, as discussed in <xref linkend="extend-types-polymorphic">.
|
||||||
An example is shown in <xref linkend="plpgsql-declaration-aliases">.
|
An example is shown in <xref linkend="plpgsql-declaration-aliases">.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<application>PL/pgSQL</> functions can also be declared to return
|
<application>PL/pgSQL</> functions can also be declared to return
|
||||||
a <quote>set</>, or table, of any datatype they can return a single
|
a <quote>set</>, or table, of any data type they can return a single
|
||||||
instance of. Such a function generates its output by executing
|
instance of. Such a function generates its output by executing
|
||||||
<literal>RETURN NEXT</> for each desired element of the result set.
|
<literal>RETURN NEXT</> for each desired element of the result set.
|
||||||
</para>
|
</para>
|
||||||
@ -563,7 +563,7 @@ END;
|
|||||||
When the return type of a <application>PL/pgSQL</application>
|
When the return type of a <application>PL/pgSQL</application>
|
||||||
function is declared as a polymorphic type (<type>anyelement</type>
|
function is declared as a polymorphic type (<type>anyelement</type>
|
||||||
or <type>anyarray</type>), a special parameter <literal>$0</literal>
|
or <type>anyarray</type>), a special parameter <literal>$0</literal>
|
||||||
is created. Its datatype is the actual return type of the function,
|
is created. Its data type is the actual return type of the function,
|
||||||
as deduced from the actual input types (see <xref
|
as deduced from the actual input types (see <xref
|
||||||
linkend="extend-types-polymorphic">).
|
linkend="extend-types-polymorphic">).
|
||||||
This allows the function to access its actual return type
|
This allows the function to access its actual return type
|
||||||
@ -571,7 +571,7 @@ END;
|
|||||||
<literal>$0</literal> is initialized to NULL and can be modified by
|
<literal>$0</literal> is initialized to NULL and can be modified by
|
||||||
the function, so it can be used to hold the return value if desired,
|
the function, so it can be used to hold the return value if desired,
|
||||||
though that is not required. <literal>$0</literal> can also be
|
though that is not required. <literal>$0</literal> can also be
|
||||||
given an alias. For example, this function works on any datatype
|
given an alias. For example, this function works on any data type
|
||||||
that has a <literal>+</> operator:
|
that has a <literal>+</> operator:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement)
|
CREATE FUNCTION add_three_values(anyelement, anyelement, anyelement)
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.46 2003/10/17 18:57:01 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.47 2003/11/01 01:56:29 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="protocol">
|
<chapter id="protocol">
|
||||||
<title>Frontend/Backend Protocol</title>
|
<title>Frontend/Backend Protocol</title>
|
||||||
@ -164,7 +164,7 @@
|
|||||||
<title>Formats and Format Codes</title>
|
<title>Formats and Format Codes</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Data of a particular datatype might be transmitted in any of several
|
Data of a particular data type might be transmitted in any of several
|
||||||
different <firstterm>formats</>. As of <productname>PostgreSQL</> 7.4
|
different <firstterm>formats</>. As of <productname>PostgreSQL</> 7.4
|
||||||
the only supported formats are <quote>text</> and <quote>binary</>,
|
the only supported formats are <quote>text</> and <quote>binary</>,
|
||||||
but the protocol makes provision for future extensions. The desired
|
but the protocol makes provision for future extensions. The desired
|
||||||
@ -178,7 +178,7 @@
|
|||||||
<para>
|
<para>
|
||||||
The text representation of values is whatever strings are produced
|
The text representation of values is whatever strings are produced
|
||||||
and accepted by the input/output conversion functions for the
|
and accepted by the input/output conversion functions for the
|
||||||
particular datatype. In the transmitted representation, there is
|
particular data type. In the transmitted representation, there is
|
||||||
no trailing null character; the frontend must add one to received
|
no trailing null character; the frontend must add one to received
|
||||||
values if it wants to process them as C strings.
|
values if it wants to process them as C strings.
|
||||||
(The text format does not allow embedded nulls, by the way.)
|
(The text format does not allow embedded nulls, by the way.)
|
||||||
@ -186,9 +186,9 @@
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Binary representations for integers use network byte order (most
|
Binary representations for integers use network byte order (most
|
||||||
significant byte first). For other datatypes consult the documentation
|
significant byte first). For other data types consult the documentation
|
||||||
or source code to learn about the binary representation. Keep in mind
|
or source code to learn about the binary representation. Keep in mind
|
||||||
that binary representations for complex datatypes may change across
|
that binary representations for complex data types may change across
|
||||||
server versions; the text format is usually the more portable choice.
|
server versions; the text format is usually the more portable choice.
|
||||||
</para>
|
</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
@ -562,7 +562,7 @@
|
|||||||
|
|
||||||
<Para>
|
<Para>
|
||||||
The response to a <command>SELECT</> query (or other queries that
|
The response to a <command>SELECT</> query (or other queries that
|
||||||
return rowsets, such as <command>EXPLAIN</> or <command>SHOW</>)
|
return row sets, such as <command>EXPLAIN</> or <command>SHOW</>)
|
||||||
normally consists of RowDescription, zero or more
|
normally consists of RowDescription, zero or more
|
||||||
DataRow messages, and then CommandComplete.
|
DataRow messages, and then CommandComplete.
|
||||||
<command>COPY</> to or from the frontend invokes special protocol
|
<command>COPY</> to or from the frontend invokes special protocol
|
||||||
@ -629,12 +629,12 @@
|
|||||||
<para>
|
<para>
|
||||||
In the extended protocol, the frontend first sends a Parse message,
|
In the extended protocol, the frontend first sends a Parse message,
|
||||||
which contains a textual query string, optionally some information
|
which contains a textual query string, optionally some information
|
||||||
about datatypes of parameter placeholders, and the
|
about data types of parameter placeholders, and the
|
||||||
name of a destination prepared-statement object (an empty string
|
name of a destination prepared-statement object (an empty string
|
||||||
selects the unnamed prepared statement). The response is
|
selects the unnamed prepared statement). The response is
|
||||||
either ParseComplete or ErrorResponse. Parameter datatypes may be
|
either ParseComplete or ErrorResponse. Parameter data types may be
|
||||||
specified by OID; if not given, the parser attempts to infer the
|
specified by OID; if not given, the parser attempts to infer the
|
||||||
datatypes in the same way as it would do for untyped literal string
|
data types in the same way as it would do for untyped literal string
|
||||||
constants.
|
constants.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -701,7 +701,7 @@
|
|||||||
unnamed portal) and
|
unnamed portal) and
|
||||||
a maximum result-row count (zero meaning <quote>fetch all rows</>).
|
a maximum result-row count (zero meaning <quote>fetch all rows</>).
|
||||||
The result-row count is only meaningful for portals
|
The result-row count is only meaningful for portals
|
||||||
containing commands that return rowsets; in other cases the command is
|
containing commands that return row sets; in other cases the command is
|
||||||
always executed to completion, and the row count is ignored.
|
always executed to completion, and the row count is ignored.
|
||||||
The possible
|
The possible
|
||||||
responses to Execute are the same as those described above for queries
|
responses to Execute are the same as those described above for queries
|
||||||
@ -995,7 +995,7 @@
|
|||||||
<command>SET</> SQL command executed by the frontend, and this case
|
<command>SET</> SQL command executed by the frontend, and this case
|
||||||
is effectively synchronous --- but it is also possible for parameter
|
is effectively synchronous --- but it is also possible for parameter
|
||||||
status changes to occur because the administrator changed a configuration
|
status changes to occur because the administrator changed a configuration
|
||||||
file and then SIGHUP'd the postmaster. Also, if a SET command is
|
file and then sent the <systemitem>SIGHUP</systemitem> signal to the postmaster. Also, if a SET command is
|
||||||
rolled back, an appropriate ParameterStatus message will be generated
|
rolled back, an appropriate ParameterStatus message will be generated
|
||||||
to report the current effective value.
|
to report the current effective value.
|
||||||
</para>
|
</para>
|
||||||
@ -1450,7 +1450,7 @@ AuthenticationCleartextPassword (B)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
Specifies that a cleartext password is required.
|
Specifies that a clear-text password is required.
|
||||||
</Para>
|
</Para>
|
||||||
</ListItem>
|
</ListItem>
|
||||||
</VarListEntry>
|
</VarListEntry>
|
||||||
@ -2126,9 +2126,9 @@ CopyData (F & B)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
Data that forms part of a COPY datastream. Messages sent
|
Data that forms part of a <command>COPY</command> data stream. Messages sent
|
||||||
from the backend will always correspond to single data rows,
|
from the backend will always correspond to single data rows,
|
||||||
but messages sent by frontends may divide the datastream
|
but messages sent by frontends may divide the data stream
|
||||||
arbitrarily.
|
arbitrarily.
|
||||||
</Para>
|
</Para>
|
||||||
</ListItem>
|
</ListItem>
|
||||||
@ -3094,7 +3094,7 @@ ParameterDescription (B)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
Specifies the object ID of the parameter datatype.
|
Specifies the object ID of the parameter data type.
|
||||||
</Para>
|
</Para>
|
||||||
</ListItem>
|
</ListItem>
|
||||||
</VarListEntry>
|
</VarListEntry>
|
||||||
@ -3213,7 +3213,7 @@ Parse (F)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
The number of parameter datatypes specified
|
The number of parameter data types specified
|
||||||
(may be zero). Note that this is not an indication of
|
(may be zero). Note that this is not an indication of
|
||||||
the number of parameters that might appear in the
|
the number of parameters that might appear in the
|
||||||
query string, only the number that the frontend wants to
|
query string, only the number that the frontend wants to
|
||||||
@ -3230,7 +3230,7 @@ Parse (F)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
Specifies the object ID of the parameter datatype.
|
Specifies the object ID of the parameter data type.
|
||||||
Placing a zero here is equivalent to leaving the type
|
Placing a zero here is equivalent to leaving the type
|
||||||
unspecified.
|
unspecified.
|
||||||
</Para>
|
</Para>
|
||||||
@ -3532,7 +3532,7 @@ RowDescription (B)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
The object ID of the field's datatype.
|
The object ID of the field's data type.
|
||||||
</Para>
|
</Para>
|
||||||
</ListItem>
|
</ListItem>
|
||||||
</VarListEntry>
|
</VarListEntry>
|
||||||
@ -3542,7 +3542,7 @@ RowDescription (B)
|
|||||||
</Term>
|
</Term>
|
||||||
<ListItem>
|
<ListItem>
|
||||||
<Para>
|
<Para>
|
||||||
The datatype size (see <varname>pg_type.typlen</>).
|
The data type size (see <varname>pg_type.typlen</>).
|
||||||
Note that negative values denote variable-width types.
|
Note that negative values denote variable-width types.
|
||||||
</Para>
|
</Para>
|
||||||
</ListItem>
|
</ListItem>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.24 2003/09/12 22:17:23 tgl Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.25 2003/11/01 01:56:29 petere Exp $ -->
|
||||||
|
|
||||||
<chapter id="queries">
|
<chapter id="queries">
|
||||||
<title>Queries</title>
|
<title>Queries</title>
|
||||||
@ -132,7 +132,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||||||
When a table reference names a table that is the supertable of a
|
When a table reference names a table that is the supertable of a
|
||||||
table inheritance hierarchy, the table reference produces rows of
|
table inheritance hierarchy, the table reference produces rows of
|
||||||
not only that table but all of its subtable successors, unless the
|
not only that table but all of its subtable successors, unless the
|
||||||
keyword <literal>ONLY</> precedes the table name. However, the
|
key word <literal>ONLY</> precedes the table name. However, the
|
||||||
reference produces only the columns that appear in the named table
|
reference produces only the columns that appear in the named table
|
||||||
--- any columns added in subtables are ignored.
|
--- any columns added in subtables are ignored.
|
||||||
</para>
|
</para>
|
||||||
@ -1244,12 +1244,12 @@ SELECT a AS b FROM table1 ORDER BY a;
|
|||||||
determined with the <literal>></literal> operator.
|
determined with the <literal>></literal> operator.
|
||||||
<footnote>
|
<footnote>
|
||||||
<para>
|
<para>
|
||||||
Actually, <productname>PostgreSQL</> uses the <firstterm>default btree
|
Actually, <productname>PostgreSQL</> uses the <firstterm>default B-tree
|
||||||
operator class</> for the column's datatype to determine the sort
|
operator class</> for the column's data type to determine the sort
|
||||||
ordering for <literal>ASC</> and <literal>DESC</>. Conventionally,
|
ordering for <literal>ASC</> and <literal>DESC</>. Conventionally,
|
||||||
datatypes will be set up so that the <literal><</literal> and
|
data types will be set up so that the <literal><</literal> and
|
||||||
<literal>></literal> operators correspond to this sort ordering,
|
<literal>></literal> operators correspond to this sort ordering,
|
||||||
but a user-defined datatype's designer could choose to do something
|
but a user-defined data type's designer could choose to do something
|
||||||
different.
|
different.
|
||||||
</para>
|
</para>
|
||||||
</footnote>
|
</footnote>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.33 2003/08/31 17:32:19 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.34 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="tutorial-sql">
|
<chapter id="tutorial-sql">
|
||||||
@ -155,7 +155,7 @@ CREATE TABLE weather (
|
|||||||
and a rich set of geometric types.
|
and a rich set of geometric types.
|
||||||
<productname>PostgreSQL</productname> can be customized with an
|
<productname>PostgreSQL</productname> can be customized with an
|
||||||
arbitrary number of user-defined data types. Consequently, type
|
arbitrary number of user-defined data types. Consequently, type
|
||||||
names are not syntactical keywords, except where required to
|
names are not syntactical key words, except where required to
|
||||||
support special cases in the <acronym>SQL</acronym> standard.
|
support special cases in the <acronym>SQL</acronym> standard.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_sequence.sgml,v 1.5 2003/09/22 00:16:57 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_sequence.sgml,v 1.6 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -49,7 +49,7 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
<term><replaceable class="parameter">name</replaceable></term>
|
<term><replaceable class="parameter">name</replaceable></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The name (optionally schema-qualified) of a sequence to be altered.
|
The name (optionally schema-qualified) of a sequence to be altered.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -58,42 +58,43 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
<term><replaceable class="parameter">increment</replaceable></term>
|
<term><replaceable class="parameter">increment</replaceable></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The
|
The clause <literal>INCREMENT BY <replaceable
|
||||||
<option>INCREMENT BY <replaceable class="parameter">increment</replaceable></option>
|
class="parameter">increment</replaceable></literal> is
|
||||||
clause is optional. A positive value will make an
|
optional. A positive value will make an ascending sequence, a
|
||||||
ascending sequence, a negative one a descending sequence.
|
negative one a descending sequence. If unspecified, the old
|
||||||
If unspecified, the old increment value will be maintained.
|
increment value will be maintained.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><replaceable class="parameter">minvalue</replaceable></term>
|
<term><replaceable class="parameter">minvalue</replaceable></term>
|
||||||
<term>NO MINVALUE</term>
|
<term><literal>NO MINVALUE</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The optional clause <option>MINVALUE
|
The optional clause <literal>MINVALUE <replaceable
|
||||||
<replaceable class="parameter">minvalue</replaceable></option>
|
class="parameter">minvalue</replaceable></literal> determines
|
||||||
determines the minimum value
|
the minimum value a sequence can generate. If <literal>NO
|
||||||
a sequence can generate. If <option>NO MINVALUE</option> is specified,
|
MINVALUE</literal> is specified, the defaults of 1 and
|
||||||
the defaults of 1 and -2^63-1 for ascending and descending sequences, respectively, will be used. If neither option is specified, the current minimum
|
-2<superscript>63</>-1 for ascending and descending sequences,
|
||||||
value will be maintained.
|
respectively, will be used. If neither option is specified,
|
||||||
|
the current minimum value will be maintained.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term><replaceable class="parameter">maxvalue</replaceable></term>
|
<term><replaceable class="parameter">maxvalue</replaceable></term>
|
||||||
<term>NO MAXVALUE</term>
|
<term><literal>NO MAXVALUE</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The optional clause <option>MAXVALUE
|
The optional clause <literal>MAXVALUE <replaceable
|
||||||
<replaceable class="parameter">maxvalue</replaceable></option>
|
class="parameter">maxvalue</replaceable></literal> determines
|
||||||
determines the maximum value for the sequence. If
|
the maximum value for the sequence. If <literal>NO
|
||||||
<option>NO MAXVALUE</option> is specified, the defaults are 2^63-1 and -1 for
|
MAXVALUE</literal> is specified, the defaults are
|
||||||
ascending and descending sequences, respectively, will be used. If
|
2<superscript>63</>-1 and -1 for ascending and descending
|
||||||
neither option is specified, the current maximum value will be
|
sequences, respectively, will be used. If neither option is
|
||||||
maintained.
|
specified, the current maximum value will be maintained.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -102,9 +103,9 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
<term><replaceable class="parameter">start</replaceable></term>
|
<term><replaceable class="parameter">start</replaceable></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The optional <option>RESTART WITH
|
The optional clause <literal>RESTART WITH <replaceable
|
||||||
<replaceable class="parameter">start</replaceable></option>
|
class="parameter">start</replaceable></literal> changes the
|
||||||
clause changes the current value of the sequence.
|
current value of the sequence.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -113,11 +114,12 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
<term><replaceable class="parameter">cache</replaceable></term>
|
<term><replaceable class="parameter">cache</replaceable></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <option>CACHE <replaceable class="parameter">cache</replaceable></option> option
|
The clause <literal>CACHE <replaceable
|
||||||
enables sequence numbers to be preallocated
|
class="parameter">cache</replaceable></literal> enables
|
||||||
and stored in memory for faster access. The minimum
|
sequence numbers to be preallocated and stored in memory for
|
||||||
value is 1 (only one value can be generated at a time, i.e., no cache).
|
faster access. The minimum value is 1 (only one value can be
|
||||||
If unspecified, the old cache value will be maintained.
|
generated at a time, i.e., no cache). If unspecified, the old
|
||||||
|
cache value will be maintained.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -126,32 +128,33 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
<term>CYCLE</term>
|
<term>CYCLE</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The optional <option>CYCLE</option> keyword may be used to enable
|
The optional <literal>CYCLE</literal> key word may be used to enable
|
||||||
the sequence to wrap around when the
|
the sequence to wrap around when the
|
||||||
<replaceable class="parameter">maxvalue</replaceable> or
|
<replaceable class="parameter">maxvalue</replaceable> or
|
||||||
<replaceable class="parameter">minvalue</replaceable> has been
|
<replaceable class="parameter">minvalue</replaceable> has been
|
||||||
reached by
|
reached by
|
||||||
an ascending or descending sequence respectively. If the limit is
|
an ascending or descending sequence respectively. If the limit is
|
||||||
reached, the next number generated will be the
|
reached, the next number generated will be the
|
||||||
<replaceable class="parameter">minvalue</replaceable> or
|
<replaceable class="parameter">minvalue</replaceable> or
|
||||||
<replaceable class="parameter">maxvalue</replaceable>,
|
<replaceable class="parameter">maxvalue</replaceable>,
|
||||||
respectively.
|
respectively.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>NO CYCLE</term>
|
<term>NO CYCLE</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
If the optional <option>NO CYCLE</option> keyword is specified, any
|
If the optional <literal>NO CYCLE</literal> key word is
|
||||||
calls to <function>nextval</function> after the sequence has reached
|
specified, any calls to <function>nextval</function> after the
|
||||||
its maximum value will return an error. If neither
|
sequence has reached its maximum value will return an error.
|
||||||
<option>CYCLE</option> or <option>NO CYCLE</option> are specified,
|
If neither <literal>CYCLE</literal> or <literal>NO
|
||||||
the old cycle behaviour will be maintained.
|
CYCLE</literal> are specified, the old cycle behaviour will be
|
||||||
</para>
|
maintained.
|
||||||
</listitem>
|
</para>
|
||||||
</varlistentry>
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
</variablelist>
|
</variablelist>
|
||||||
</para>
|
</para>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
@ -161,10 +164,10 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Restart a sequence called <literal>serial</literal>, at 105:
|
Restart a sequence called <literal>serial</literal>, at 105:
|
||||||
</para>
|
<programlisting>
|
||||||
<programlisting>
|
|
||||||
ALTER SEQUENCE serial RESTART WITH 105;
|
ALTER SEQUENCE serial RESTART WITH 105;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
</para>
|
||||||
</refsect1>
|
</refsect1>
|
||||||
|
|
||||||
<refsect1>
|
<refsect1>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.72 2003/09/09 18:28:52 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.73 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -182,8 +182,8 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <literal>LIKE</literal> clause specifies a table from which
|
The <literal>LIKE</literal> clause specifies a table from which
|
||||||
the new table automatically inherits all column names, their datatypes, and
|
the new table automatically inherits all column names, their data types, and
|
||||||
<literal>NOT NULL</literal> constraints.
|
not-null constraints.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Unlike <literal>INHERITS</literal>, the new table and inherited table
|
Unlike <literal>INHERITS</literal>, the new table and inherited table
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.46 2003/09/22 00:16:57 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.47 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -116,7 +116,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable> (
|
|||||||
representation. If this function is not supplied, the type cannot
|
representation. If this function is not supplied, the type cannot
|
||||||
participate in binary input. The binary representation should be
|
participate in binary input. The binary representation should be
|
||||||
chosen to be cheap to convert to internal form, while being reasonably
|
chosen to be cheap to convert to internal form, while being reasonably
|
||||||
portable. (For example, the standard integer datatypes use network
|
portable. (For example, the standard integer data types use network
|
||||||
byte order as the external binary representation, while the internal
|
byte order as the external binary representation, while the internal
|
||||||
representation is in the machine's native byte order.) The receive
|
representation is in the machine's native byte order.) The receive
|
||||||
function should perform adequate checking to ensure that the value is
|
function should perform adequate checking to ensure that the value is
|
||||||
@ -124,7 +124,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable> (
|
|||||||
The receive function may be declared as taking one argument of type
|
The receive function may be declared as taking one argument of type
|
||||||
<type>internal</type>, or two arguments of types <type>internal</type>
|
<type>internal</type>, or two arguments of types <type>internal</type>
|
||||||
and <type>oid</type>. It must return a value of the data type itself.
|
and <type>oid</type>. It must return a value of the data type itself.
|
||||||
(The first argument is a pointer to a StringInfo buffer
|
(The first argument is a pointer to a <type>StringInfo</type> buffer
|
||||||
holding the received byte string; the optional second argument is the
|
holding the received byte string; the optional second argument is the
|
||||||
element type in case this is an array type.) Similarly, the optional
|
element type in case this is an array type.) Similarly, the optional
|
||||||
<replaceable class="parameter">send_function</replaceable> converts
|
<replaceable class="parameter">send_function</replaceable> converts
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.26 2003/09/28 01:19:33 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.27 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -30,7 +30,7 @@ class="PARAMETER">column_name</replaceable> [, ...] ) ] AS <replaceable class="P
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>CREATE VIEW</command> defines a view of a query. The view
|
<command>CREATE VIEW</command> defines a view of a query. The view
|
||||||
is not physically materialized. Instead, the query is run everytime
|
is not physically materialized. Instead, the query is run every time
|
||||||
the view is referenced in a query.
|
the view is referenced in a query.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -112,7 +112,7 @@ class="PARAMETER">column_name</replaceable> [, ...] ) ] AS <replaceable class="P
|
|||||||
CREATE VIEW vista AS SELECT 'Hello World';
|
CREATE VIEW vista AS SELECT 'Hello World';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
is bad form in two ways: the column name defaults to <literal>?column?</>,
|
is bad form in two ways: the column name defaults to <literal>?column?</>,
|
||||||
and the column datatype defaults to <type>unknown</>. If you want a
|
and the column data type defaults to <type>unknown</>. If you want a
|
||||||
string literal in a view's result, use something like
|
string literal in a view's result, use something like
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
|
CREATE VIEW vista AS SELECT text 'Hello World' AS hello;
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.23 2003/08/31 17:32:23 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.24 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -220,8 +220,8 @@ PostgreSQL documentation
|
|||||||
shutdown is indicated by removal of the <acronym>PID</acronym>
|
shutdown is indicated by removal of the <acronym>PID</acronym>
|
||||||
file. For starting up, a successful <command>psql -l</command>
|
file. For starting up, a successful <command>psql -l</command>
|
||||||
indicates success. <command>pg_ctl</command> will attempt to
|
indicates success. <command>pg_ctl</command> will attempt to
|
||||||
use the proper port for psql. If the environment variable
|
use the proper port for <application>psql</>. If the environment variable
|
||||||
PGPORT exists, that is used. Otherwise, it will see if a port
|
<envar>PGPORT</envar> exists, that is used. Otherwise, it will see if a port
|
||||||
has been set in the <filename>postgresql.conf</filename> file.
|
has been set in the <filename>postgresql.conf</filename> file.
|
||||||
If neither of those is used, it will use the default port that
|
If neither of those is used, it will use the default port that
|
||||||
<productname>PostgreSQL</productname> was compiled with
|
<productname>PostgreSQL</productname> was compiled with
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.98 2003/10/04 01:04:46 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.99 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -96,7 +96,7 @@ PostgreSQL documentation
|
|||||||
processed in a single transaction, unless there are explicit
|
processed in a single transaction, unless there are explicit
|
||||||
BEGIN/COMMIT commands included in the string to divide it into
|
BEGIN/COMMIT commands included in the string to divide it into
|
||||||
multiple transactions. This is different from the behavior when
|
multiple transactions. This is different from the behavior when
|
||||||
the same string is fed to psql's standard input.
|
the same string is fed to <application>psql</application>'s standard input.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.70 2003/09/11 21:42:20 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.71 2003/11/01 01:56:29 petere Exp $
|
||||||
PostgreSQL documentation
|
PostgreSQL documentation
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -666,7 +666,7 @@ SELECT name FROM distributors ORDER BY code;
|
|||||||
name may be specified in the <literal>USING</> clause.
|
name may be specified in the <literal>USING</> clause.
|
||||||
<literal>ASC</> is usually equivalent to <literal>USING <</> and
|
<literal>ASC</> is usually equivalent to <literal>USING <</> and
|
||||||
<literal>DESC</> is usually equivalent to <literal>USING ></>.
|
<literal>DESC</> is usually equivalent to <literal>USING ></>.
|
||||||
(But the creator of a user-defined datatype can define exactly what the
|
(But the creator of a user-defined data type can define exactly what the
|
||||||
default sort ordering is, and it might correspond to operators with other
|
default sort ordering is, and it might correspond to operators with other
|
||||||
names.)
|
names.)
|
||||||
</para>
|
</para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.234 2003/10/31 22:22:10 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.235 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<appendix id="release">
|
<appendix id="release">
|
||||||
@ -181,7 +181,7 @@ required for those wishing to migrate data from any previous release.</para>
|
|||||||
<listitem><para> MOVE/FETCH now returns the actual number of rows moved/fetched, or zero
|
<listitem><para> MOVE/FETCH now returns the actual number of rows moved/fetched, or zero
|
||||||
if at the beginning/end of the cursor</para>
|
if at the beginning/end of the cursor</para>
|
||||||
<para>
|
<para>
|
||||||
Prior releases would return the tuple count passed to the
|
Prior releases would return the row count passed to the
|
||||||
command, not the actual number of rows FETCHed or MOVEd.
|
command, not the actual number of rows FETCHed or MOVEd.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -1588,7 +1588,7 @@ of locale?</para></listitem>
|
|||||||
<listitem><para>Disable LIMIT #,# syntax; now only LIMIT # OFFSET # supported (Bruce)</para></listitem>
|
<listitem><para>Disable LIMIT #,# syntax; now only LIMIT # OFFSET # supported (Bruce)</para></listitem>
|
||||||
<listitem><para>Increase identifier length to 63 (Neil, Bruce)</para></listitem>
|
<listitem><para>Increase identifier length to 63 (Neil, Bruce)</para></listitem>
|
||||||
<listitem><para>UNION fixes for merging >= 3 columns of different lengths (Tom)</para></listitem>
|
<listitem><para>UNION fixes for merging >= 3 columns of different lengths (Tom)</para></listitem>
|
||||||
<listitem><para>Add DEFAULT keyword to INSERT, e.g., INSERT ... (..., DEFAULT, ...) (Rod)</para></listitem>
|
<listitem><para>Add DEFAULT key word to INSERT, e.g., INSERT ... (..., DEFAULT, ...) (Rod)</para></listitem>
|
||||||
<listitem><para>Allow views to have default values using ALTER COLUMN ... SET DEFAULT (Neil)</para></listitem>
|
<listitem><para>Allow views to have default values using ALTER COLUMN ... SET DEFAULT (Neil)</para></listitem>
|
||||||
<listitem><para>Fail on INSERTs with column lists that don't supply all column values, e.g., INSERT INTO tab (col1, col2) VALUES ('val1'); (Rod)</para></listitem>
|
<listitem><para>Fail on INSERTs with column lists that don't supply all column values, e.g., INSERT INTO tab (col1, col2) VALUES ('val1'); (Rod)</para></listitem>
|
||||||
<listitem><para>Fix for join aliases (Tom)</para></listitem>
|
<listitem><para>Fix for join aliases (Tom)</para></listitem>
|
||||||
@ -2739,7 +2739,7 @@ AIX, MSWIN, VAX, N32K fixes (Tom)
|
|||||||
Multibytes fixes (Tom)
|
Multibytes fixes (Tom)
|
||||||
Unicode fixes (Tatsuo)
|
Unicode fixes (Tatsuo)
|
||||||
Optimizer improvements (Tom)
|
Optimizer improvements (Tom)
|
||||||
Fix for whole tuples in functions (Tom)
|
Fix for whole rows in functions (Tom)
|
||||||
Fix for pg_ctl and option strings with spaces (Peter E)
|
Fix for pg_ctl and option strings with spaces (Peter E)
|
||||||
ODBC fixes (Hiroshi)
|
ODBC fixes (Hiroshi)
|
||||||
EXTRACT can now take string argument (Thomas)
|
EXTRACT can now take string argument (Thomas)
|
||||||
@ -2890,7 +2890,7 @@ Modify pg_dump to better handle user-defined items in template1 (Philip)
|
|||||||
Allow LIMIT in VIEW (Tom)
|
Allow LIMIT in VIEW (Tom)
|
||||||
Require cursor FETCH to honor LIMIT (Tom)
|
Require cursor FETCH to honor LIMIT (Tom)
|
||||||
Allow PRIMARY/FOREIGN Key definitions on inherited columns (Stephan)
|
Allow PRIMARY/FOREIGN Key definitions on inherited columns (Stephan)
|
||||||
Allow ORDER BY, LIMIT in sub-selects (Tom)
|
Allow ORDER BY, LIMIT in subqueries (Tom)
|
||||||
Allow UNION in CREATE RULE (Tom)
|
Allow UNION in CREATE RULE (Tom)
|
||||||
Make ALTER/DROP TABLE rollback-able (Vadim, Tom)
|
Make ALTER/DROP TABLE rollback-able (Vadim, Tom)
|
||||||
Store initdb collation in pg_control so collation cannot be changed (Tom)
|
Store initdb collation in pg_control so collation cannot be changed (Tom)
|
||||||
@ -2923,7 +2923,7 @@ Improved handling of file descriptor cache (Tom)
|
|||||||
New warning code about auto-created table alias entries (Bruce)
|
New warning code about auto-created table alias entries (Bruce)
|
||||||
Overhaul initdb process (Tom, Peter E)
|
Overhaul initdb process (Tom, Peter E)
|
||||||
Overhaul of inherited tables; inherited tables now accessed by default;
|
Overhaul of inherited tables; inherited tables now accessed by default;
|
||||||
new ONLY keyword prevents it (Chris Bitmead, Tom)
|
new ONLY key word prevents it (Chris Bitmead, Tom)
|
||||||
ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs,
|
ODBC cleanups/improvements (Nick Gorham, Stephan Szabo, Zoltan Kovacs,
|
||||||
Michael Fork)
|
Michael Fork)
|
||||||
Allow renaming of temp tables (Tom)
|
Allow renaming of temp tables (Tom)
|
||||||
@ -2931,7 +2931,7 @@ Overhaul memory manager contexts (Tom)
|
|||||||
pg_dumpall uses CREATE USER or CREATE GROUP rather using COPY (Peter E)
|
pg_dumpall uses CREATE USER or CREATE GROUP rather using COPY (Peter E)
|
||||||
Overhaul pg_dump (Philip Warner)
|
Overhaul pg_dump (Philip Warner)
|
||||||
Allow pg_hba.conf secondary password file to specify only username (Peter E)
|
Allow pg_hba.conf secondary password file to specify only username (Peter E)
|
||||||
Allow TEMPORARY or TEMP keyword when creating temporary tables (Bruce)
|
Allow TEMPORARY or TEMP key word when creating temporary tables (Bruce)
|
||||||
New memory leak checker (Karel)
|
New memory leak checker (Karel)
|
||||||
New SET SESSION CHARACTERISTICS (Thomas)
|
New SET SESSION CHARACTERISTICS (Thomas)
|
||||||
Allow nested block comments (Thomas)
|
Allow nested block comments (Thomas)
|
||||||
@ -3104,8 +3104,8 @@ Fix for mergejoin plans (Tom)
|
|||||||
Fix TRUNCATE failure on relations with indexes (Tom)
|
Fix TRUNCATE failure on relations with indexes (Tom)
|
||||||
Avoid database-wide restart on write error (Hiroshi)
|
Avoid database-wide restart on write error (Hiroshi)
|
||||||
Fix nodeMaterial to honor chgParam by recomputing its output (Tom)
|
Fix nodeMaterial to honor chgParam by recomputing its output (Tom)
|
||||||
Fix VACUUM problem with moving chain of update tuples when source and
|
Fix VACUUM problem with moving chain of update row versions when source
|
||||||
destination of a tuple lie on the same page (Tom)
|
and destination of a row version lie on the same page (Tom)
|
||||||
Fix user.c CommandCounterIncrement (Tom)
|
Fix user.c CommandCounterIncrement (Tom)
|
||||||
Fix for AM/PM boundary problem in to_char() (Karel Zak)
|
Fix for AM/PM boundary problem in to_char() (Karel Zak)
|
||||||
Fix TIME aggregate handling (Tom)
|
Fix TIME aggregate handling (Tom)
|
||||||
@ -3538,7 +3538,7 @@ Add btree indexing of boolean values, >= and <= (Don Baccus)
|
|||||||
Print current line number when COPY FROM fails (Massimo)
|
Print current line number when COPY FROM fails (Massimo)
|
||||||
Recognize POSIX time zone e.g. "PST+8" and "GMT-8" (Thomas)
|
Recognize POSIX time zone e.g. "PST+8" and "GMT-8" (Thomas)
|
||||||
Add DEC as synonym for DECIMAL (Thomas)
|
Add DEC as synonym for DECIMAL (Thomas)
|
||||||
Add SESSION_USER as SQL92 keyword, same as CURRENT_USER (Thomas)
|
Add SESSION_USER as SQL92 key word, same as CURRENT_USER (Thomas)
|
||||||
Implement SQL92 column aliases (aka correlation names) (Thomas)
|
Implement SQL92 column aliases (aka correlation names) (Thomas)
|
||||||
Implement SQL92 join syntax (Thomas)
|
Implement SQL92 join syntax (Thomas)
|
||||||
Make INTERVAL reserved word allowed as a column identifier (Thomas)
|
Make INTERVAL reserved word allowed as a column identifier (Thomas)
|
||||||
@ -3822,7 +3822,7 @@ ACL file descriptor leak fix(Atsushi Ogawa)
|
|||||||
New expresssion subtree code(Tom)
|
New expresssion subtree code(Tom)
|
||||||
Avoid disk writes for read-only transactions(Vadim)
|
Avoid disk writes for read-only transactions(Vadim)
|
||||||
Fix for removal of temp tables if last transaction was aborted(Bruce)
|
Fix for removal of temp tables if last transaction was aborted(Bruce)
|
||||||
Fix to prevent too large tuple from being created(Bruce)
|
Fix to prevent too large row from being created(Bruce)
|
||||||
plpgsql fixes
|
plpgsql fixes
|
||||||
Allow port numbers 32k - 64k(Bruce)
|
Allow port numbers 32k - 64k(Bruce)
|
||||||
Add ^ precidence(Bruce)
|
Add ^ precidence(Bruce)
|
||||||
@ -4226,7 +4226,7 @@ Port to NetBSD/m68k(Mr. Mutsuki Nakajima)
|
|||||||
Port to NetBSD/sun3(Mr. Mutsuki Nakajima)
|
Port to NetBSD/sun3(Mr. Mutsuki Nakajima)
|
||||||
Port to NetBSD/macppc(Toshimi Aoki)
|
Port to NetBSD/macppc(Toshimi Aoki)
|
||||||
Fix for tcl/tk configuration(Vince)
|
Fix for tcl/tk configuration(Vince)
|
||||||
Removed CURRENT keyword for rule queries(Jan)
|
Removed CURRENT key word for rule queries(Jan)
|
||||||
NT dynamic loading now works(Daniel Horak)
|
NT dynamic loading now works(Daniel Horak)
|
||||||
Add ARM32 support(Andrew McMurry)
|
Add ARM32 support(Andrew McMurry)
|
||||||
Better support for HP-UX 11 and UnixWare
|
Better support for HP-UX 11 and UnixWare
|
||||||
@ -4589,7 +4589,7 @@ New INSERT INTO TABLE DEFAULT VALUES statement available(Thomas)
|
|||||||
New DECLARE and FETCH feature(Thomas)
|
New DECLARE and FETCH feature(Thomas)
|
||||||
libpq's internal structures now not exported(Tom)
|
libpq's internal structures now not exported(Tom)
|
||||||
Allow up to 8 key indexes(Bruce)
|
Allow up to 8 key indexes(Bruce)
|
||||||
Remove ARCHIVE keyword, that is no longer used(Thomas)
|
Remove ARCHIVE key word, that is no longer used(Thomas)
|
||||||
pg_dump -n flag to supress quotes around indentifiers
|
pg_dump -n flag to supress quotes around indentifiers
|
||||||
disable system columns for views(Jan)
|
disable system columns for views(Jan)
|
||||||
new INET and CIDR types for network addresses(TomH, Paul)
|
new INET and CIDR types for network addresses(TomH, Paul)
|
||||||
@ -4777,7 +4777,7 @@ Fix for "Datasize = 0" error(Vadim)
|
|||||||
Prevent \do from wrapping(Bruce)
|
Prevent \do from wrapping(Bruce)
|
||||||
Remove duplicate Russian character set entries
|
Remove duplicate Russian character set entries
|
||||||
Sunos4 cleanup
|
Sunos4 cleanup
|
||||||
Allow optional TABLE keyword in LOCK and SELECT INTO(Thomas)
|
Allow optional TABLE key word in LOCK and SELECT INTO(Thomas)
|
||||||
CREATE SEQUENCE options to allow a negative integer(Thomas)
|
CREATE SEQUENCE options to allow a negative integer(Thomas)
|
||||||
Add "PASSWORD" as an allowed column identifier(Thomas)
|
Add "PASSWORD" as an allowed column identifier(Thomas)
|
||||||
Add checks for UNION target fields(Bruce)
|
Add checks for UNION target fields(Bruce)
|
||||||
@ -4971,7 +4971,7 @@ Fix for index scans in MergeJion(Vadim)
|
|||||||
|
|
||||||
Enhancements
|
Enhancements
|
||||||
------------
|
------------
|
||||||
Subselects with EXISTS, IN, ALL, ANY keywords (Vadim, Bruce, Thomas)
|
Subselects with EXISTS, IN, ALL, ANY key words (Vadim, Bruce, Thomas)
|
||||||
New User Manual(Thomas, others)
|
New User Manual(Thomas, others)
|
||||||
Speedup by inlining some frequently-called functions
|
Speedup by inlining some frequently-called functions
|
||||||
Real deadlock detection, no more timeouts(Bruce)
|
Real deadlock detection, no more timeouts(Bruce)
|
||||||
@ -5089,7 +5089,7 @@ Bring in the PostODBC source tree as part of our standard distribution(Marc)
|
|||||||
A minor patch for HP/UX 10 vs 9(Stan)
|
A minor patch for HP/UX 10 vs 9(Stan)
|
||||||
New pg_attribute.atttypmod for type-specific info like varchar length(Bruce)
|
New pg_attribute.atttypmod for type-specific info like varchar length(Bruce)
|
||||||
UnixWare patches(Billy)
|
UnixWare patches(Billy)
|
||||||
New i386 'lock' for spin lock asm(Billy)
|
New i386 'lock' for spinlock asm(Billy)
|
||||||
Support for multiplexed backends is removed
|
Support for multiplexed backends is removed
|
||||||
Start an OpenBSD port
|
Start an OpenBSD port
|
||||||
Start an AUX port
|
Start an AUX port
|
||||||
@ -5234,13 +5234,13 @@ Check for geometric intersections at endpoints to avoid rounding ugliness(Thomas
|
|||||||
Catch non-functional delete attempts(Vadim)
|
Catch non-functional delete attempts(Vadim)
|
||||||
Change time function names to be more consistent(Michael Reifenberg)
|
Change time function names to be more consistent(Michael Reifenberg)
|
||||||
Check for zero divides(Michael Reifenberg)
|
Check for zero divides(Michael Reifenberg)
|
||||||
Fix very old bug which made tuples changed/inserted by a commnd
|
Fix very old bug which made rows changed/inserted by a command
|
||||||
visible to the command itself (so we had multiple update of
|
visible to the command itself (so we had multiple update of
|
||||||
updated tuples, etc)(Vadim)
|
updated rows, etc.)(Vadim)
|
||||||
Fix for SELECT null, 'fail' FROM pg_am (Patrick)
|
Fix for SELECT null, 'fail' FROM pg_am (Patrick)
|
||||||
SELECT NULL as EMPTY_FIELD now allowed(Patrick)
|
SELECT NULL as EMPTY_FIELD now allowed(Patrick)
|
||||||
Remove un-needed signal stuff from contrib/pginterface
|
Remove un-needed signal stuff from contrib/pginterface
|
||||||
Fix OR (where x != 1 or x isnull didn't return tuples with x NULL) (Vadim)
|
Fix OR (where x != 1 or x isnull didn't return rows with x NULL) (Vadim)
|
||||||
Fix time_cmp function (Vadim)
|
Fix time_cmp function (Vadim)
|
||||||
Fix handling of functions with non-attribute first argument in
|
Fix handling of functions with non-attribute first argument in
|
||||||
WHERE clauses (Vadim)
|
WHERE clauses (Vadim)
|
||||||
@ -5254,7 +5254,7 @@ Default genetic optimizer GEQO parameter is now 8(Bruce)
|
|||||||
Allow use parameters in target list having aggregates in functions(Vadim)
|
Allow use parameters in target list having aggregates in functions(Vadim)
|
||||||
Added JDBC driver as an interface(Adrian & Peter)
|
Added JDBC driver as an interface(Adrian & Peter)
|
||||||
pg_password utility
|
pg_password utility
|
||||||
Return number of tuples inserted/affected by INSERT/UPDATE/DELETE etc.(Vadim)
|
Return number of rows inserted/affected by INSERT/UPDATE/DELETE etc.(Vadim)
|
||||||
Triggers implemented with CREATE TRIGGER (SQL3)(Vadim)
|
Triggers implemented with CREATE TRIGGER (SQL3)(Vadim)
|
||||||
SPI (Server Programming Interface) allows execution of queries inside
|
SPI (Server Programming Interface) allows execution of queries inside
|
||||||
C-functions (Vadim)
|
C-functions (Vadim)
|
||||||
@ -5481,7 +5481,7 @@ fix local buffers leak in transaction aborts (Vadim)
|
|||||||
fix file manager memmory leaks, cleanups (Vadim, Massimo)
|
fix file manager memmory leaks, cleanups (Vadim, Massimo)
|
||||||
fix storage manager memmory leaks (Vadim)
|
fix storage manager memmory leaks (Vadim)
|
||||||
fix btree duplicates handling (Vadim)
|
fix btree duplicates handling (Vadim)
|
||||||
fix deleted tuples re-incarnation caused by vacuum (Vadim)
|
fix deleted rows reincarnation caused by vacuum (Vadim)
|
||||||
fix SELECT varchar()/char() INTO TABLE made zero-length fields(Bruce)
|
fix SELECT varchar()/char() INTO TABLE made zero-length fields(Bruce)
|
||||||
many psql, pg_dump, and libpq memory leaks fixed using Purify (Igor)
|
many psql, pg_dump, and libpq memory leaks fixed using Purify (Igor)
|
||||||
|
|
||||||
@ -6026,7 +6026,7 @@ Enhancements:
|
|||||||
* added PQdisplayTuples() to libpq and changed monitor and psql to use it
|
* added PQdisplayTuples() to libpq and changed monitor and psql to use it
|
||||||
* added NeXT port (requires SysVIPC implementation)
|
* added NeXT port (requires SysVIPC implementation)
|
||||||
* added CAST .. AS ... syntax
|
* added CAST .. AS ... syntax
|
||||||
* added ASC and DESC keywords
|
* added ASC and DESC key words
|
||||||
* added 'internal' as a possible language for CREATE FUNCTION
|
* added 'internal' as a possible language for CREATE FUNCTION
|
||||||
internal functions are C functions which have been statically linked
|
internal functions are C functions which have been statically linked
|
||||||
into the postgres backend.
|
into the postgres backend.
|
||||||
@ -6075,7 +6075,7 @@ Copyright change:
|
|||||||
Incompatibilities:
|
Incompatibilities:
|
||||||
* date formats have to be MM-DD-YYYY (or DD-MM-YYYY if you're using
|
* date formats have to be MM-DD-YYYY (or DD-MM-YYYY if you're using
|
||||||
EUROPEAN STYLE). This follows SQL-92 specs.
|
EUROPEAN STYLE). This follows SQL-92 specs.
|
||||||
* "delimiters" is now a keyword
|
* "delimiters" is now a key word
|
||||||
|
|
||||||
Enhancements:
|
Enhancements:
|
||||||
* sql LIKE syntax has been added
|
* sql LIKE syntax has been added
|
||||||
@ -6160,10 +6160,10 @@ more compliant to the SQL-92 standard):
|
|||||||
(Also, aggregates can now be overloaded, i.e. you can define your
|
(Also, aggregates can now be overloaded, i.e. you can define your
|
||||||
own MAX aggregate to take in a user-defined type.)
|
own MAX aggregate to take in a user-defined type.)
|
||||||
* CHANGE ACL removed. GRANT/REVOKE syntax added.
|
* CHANGE ACL removed. GRANT/REVOKE syntax added.
|
||||||
- Privileges can be given to a group using the "GROUP" keyword.
|
- Privileges can be given to a group using the "GROUP" key word.
|
||||||
For example:
|
For example:
|
||||||
GRANT SELECT ON foobar TO GROUP my_group;
|
GRANT SELECT ON foobar TO GROUP my_group;
|
||||||
The keyword 'PUBLIC' is also supported to mean all users.
|
The key word 'PUBLIC' is also supported to mean all users.
|
||||||
|
|
||||||
Privileges can only be granted or revoked to one user or group
|
Privileges can only be granted or revoked to one user or group
|
||||||
at a time.
|
at a time.
|
||||||
@ -6180,7 +6180,7 @@ Bug fixes:
|
|||||||
* the bug where aggregates of empty tables were not run has been fixed. Now,
|
* the bug where aggregates of empty tables were not run has been fixed. Now,
|
||||||
aggregates run on empty tables will return the initial conditions of the
|
aggregates run on empty tables will return the initial conditions of the
|
||||||
aggregates. Thus, COUNT of an empty table will now properly return 0.
|
aggregates. Thus, COUNT of an empty table will now properly return 0.
|
||||||
MAX/MIN of an empty table will return a tuple of value NULL.
|
MAX/MIN of an empty table will return a row of value NULL.
|
||||||
* allow the use of \; inside the monitor
|
* allow the use of \; inside the monitor
|
||||||
* the LISTEN/NOTIFY asynchronous notification mechanism now work
|
* the LISTEN/NOTIFY asynchronous notification mechanism now work
|
||||||
* NOTIFY in rule action bodies now work
|
* NOTIFY in rule action bodies now work
|
||||||
@ -6206,7 +6206,7 @@ Other changes and enhancements:
|
|||||||
|
|
||||||
libpgtcl changes:
|
libpgtcl changes:
|
||||||
* The -oid option has been added to the "pg_result" tcl command.
|
* The -oid option has been added to the "pg_result" tcl command.
|
||||||
pg_result -oid returns oid of the last tuple inserted. If the
|
pg_result -oid returns oid of the last row inserted. If the
|
||||||
last command was not an INSERT, then pg_result -oid returns "".
|
last command was not an INSERT, then pg_result -oid returns "".
|
||||||
* the large object interface is available as pg_lo* tcl commands:
|
* the large object interface is available as pg_lo* tcl commands:
|
||||||
pg_lo_open, pg_lo_close, pg_lo_creat, etc.
|
pg_lo_open, pg_lo_close, pg_lo_creat, etc.
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.30 2003/09/11 21:42:20 momjian Exp $ -->
|
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.31 2003/11/01 01:56:29 petere Exp $ -->
|
||||||
|
|
||||||
<Chapter Id="rules">
|
<Chapter Id="rules">
|
||||||
<Title>The Rule System</Title>
|
<Title>The Rule System</Title>
|
||||||
@ -770,7 +770,7 @@ SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
|
|||||||
the stage. Old table rows aren't overwritten, and this
|
the stage. Old table rows aren't overwritten, and this
|
||||||
is why <command>ROLLBACK</command> is fast. In an <command>UPDATE</command>,
|
is why <command>ROLLBACK</command> is fast. In an <command>UPDATE</command>,
|
||||||
the new result row is inserted into the table (after stripping the
|
the new result row is inserted into the table (after stripping the
|
||||||
<acronym>CTID</>) and in the tuple header of the old row, which the
|
<acronym>CTID</>) and in the row header of the old row, which the
|
||||||
<acronym>CTID</> pointed to, the <literal>cmax</> and
|
<acronym>CTID</> pointed to, the <literal>cmax</> and
|
||||||
<literal>xmax</> entries are set to the current command counter
|
<literal>xmax</> entries are set to the current command counter
|
||||||
and current transaction ID. Thus the old row is hidden, and after
|
and current transaction ID. Thus the old row is hidden, and after
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.214 2003/10/17 22:38:20 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.215 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<Chapter Id="runtime">
|
<Chapter Id="runtime">
|
||||||
@ -878,9 +878,9 @@ SET ENABLE_SEQSCAN TO OFF;
|
|||||||
<para>
|
<para>
|
||||||
Specifies the maximum amount of memory to be used by
|
Specifies the maximum amount of memory to be used by
|
||||||
<command>VACUUM</command> to keep track of to-be-reclaimed
|
<command>VACUUM</command> to keep track of to-be-reclaimed
|
||||||
tuples. The value is specified in kilobytes, and defaults to
|
rows. The value is specified in kilobytes, and defaults to
|
||||||
8192 kilobytes. Larger settings may improve the speed of
|
8192 kB. Larger settings may improve the speed of
|
||||||
vacuuming large tables that have many deleted tuples.
|
vacuuming large tables that have many deleted rows.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1333,7 +1333,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Sets the query planner's estimate of the cost of processing
|
Sets the query planner's estimate of the cost of processing
|
||||||
each tuple during a query. This is measured as a fraction of
|
each row during a query. This is measured as a fraction of
|
||||||
the cost of a sequential page fetch. The default is 0.01.
|
the cost of a sequential page fetch. The default is 0.01.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -1344,7 +1344,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Sets the query planner's estimate of the cost of processing
|
Sets the query planner's estimate of the cost of processing
|
||||||
each index tuple during an index scan. This is measured as a
|
each index row during an index scan. This is measured as a
|
||||||
fraction of the cost of a sequential page fetch. The default
|
fraction of the cost of a sequential page fetch. The default
|
||||||
is 0.001.
|
is 0.001.
|
||||||
</para>
|
</para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.84 2003/08/31 17:32:20 petere Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.85 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="sql-syntax">
|
<chapter id="sql-syntax">
|
||||||
@ -1050,7 +1050,7 @@ CREATE FUNCTION dept(text) RETURNS dept
|
|||||||
</simplelist>
|
</simplelist>
|
||||||
where the <replaceable>operator</replaceable> token follows the syntax
|
where the <replaceable>operator</replaceable> token follows the syntax
|
||||||
rules of <xref linkend="sql-syntax-operators">, or is one of the
|
rules of <xref linkend="sql-syntax-operators">, or is one of the
|
||||||
keywords <token>AND</token>, <token>OR</token>, and
|
key words <token>AND</token>, <token>OR</token>, and
|
||||||
<token>NOT</token>, or is a qualified operator name
|
<token>NOT</token>, or is a qualified operator name
|
||||||
<synopsis>
|
<synopsis>
|
||||||
<literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
|
<literal>OPERATOR(</><replaceable>schema</><literal>.</><replaceable>operatorname</><literal>)</>
|
||||||
@ -1292,7 +1292,7 @@ SELECT name, (SELECT max(pop) FROM cities WHERE cities.state = states.name)
|
|||||||
An <firstterm>array constructor</> is an expression that builds an
|
An <firstterm>array constructor</> is an expression that builds an
|
||||||
array value from values for its member elements. A simple array
|
array value from values for its member elements. A simple array
|
||||||
constructor
|
constructor
|
||||||
consists of the keyword <literal>ARRAY</literal>, a left square bracket
|
consists of the key word <literal>ARRAY</literal>, a left square bracket
|
||||||
<literal>[</>, one or more expressions (separated by commas) for the
|
<literal>[</>, one or more expressions (separated by commas) for the
|
||||||
array element values, and finally a right square bracket <literal>]</>.
|
array element values, and finally a right square bracket <literal>]</>.
|
||||||
For example,
|
For example,
|
||||||
@ -1311,7 +1311,7 @@ SELECT ARRAY[1,2,3+4];
|
|||||||
<para>
|
<para>
|
||||||
Multidimensional array values can be built by nesting array
|
Multidimensional array values can be built by nesting array
|
||||||
constructors.
|
constructors.
|
||||||
In the inner constructors, the keyword <literal>ARRAY</literal> may
|
In the inner constructors, the key word <literal>ARRAY</literal> may
|
||||||
be omitted. For example, these produce the same result:
|
be omitted. For example, these produce the same result:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@ -1352,7 +1352,7 @@ select ARRAY[f1, f2, '{{9,10},{11,12}}'::int[]] from arr;
|
|||||||
<para>
|
<para>
|
||||||
It is also possible to construct an array from the results of a
|
It is also possible to construct an array from the results of a
|
||||||
subquery. In this form, the array constructor is written with the
|
subquery. In this form, the array constructor is written with the
|
||||||
keyword <literal>ARRAY</literal> followed by a parenthesized (not
|
key word <literal>ARRAY</literal> followed by a parenthesized (not
|
||||||
bracketed) subquery. For example:
|
bracketed) subquery. For example:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
|
SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
|
||||||
@ -1361,9 +1361,9 @@ SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
|
|||||||
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
|
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
|
||||||
(1 row)
|
(1 row)
|
||||||
</programlisting>
|
</programlisting>
|
||||||
The sub-select must return a single column. The
|
The subquery must return a single column. The
|
||||||
resulting one-dimensional array will have an element for each row in the
|
resulting one-dimensional array will have an element for each row in the
|
||||||
sub-select result, with an element type matching that of the sub-select's
|
subquery result, with an element type matching that of the subquery's
|
||||||
output column.
|
output column.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.35 2003/09/30 03:22:33 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/typeconv.sgml,v 1.36 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter Id="typeconv">
|
<chapter Id="typeconv">
|
||||||
@ -297,7 +297,7 @@ If only one candidate remains, use it; else continue to the next step.
|
|||||||
<step performance="required">
|
<step performance="required">
|
||||||
<para>
|
<para>
|
||||||
Run through all candidates and keep those that accept preferred types (of the
|
Run through all candidates and keep those that accept preferred types (of the
|
||||||
input datatype's type category) at the most positions where type conversion
|
input data type's type category) at the most positions where type conversion
|
||||||
will be required.
|
will be required.
|
||||||
Keep all candidates if none accept preferred types.
|
Keep all candidates if none accept preferred types.
|
||||||
If only one candidate remains, use it; else continue to the next step.
|
If only one candidate remains, use it; else continue to the next step.
|
||||||
@ -550,7 +550,7 @@ If only one candidate remains, use it; else continue to the next step.
|
|||||||
<step performance="required">
|
<step performance="required">
|
||||||
<para>
|
<para>
|
||||||
Run through all candidates and keep those that accept preferred types (of the
|
Run through all candidates and keep those that accept preferred types (of the
|
||||||
input datatype's type category) at the most positions where type conversion
|
input data type's type category) at the most positions where type conversion
|
||||||
will be required.
|
will be required.
|
||||||
Keep all candidates if none accept preferred types.
|
Keep all candidates if none accept preferred types.
|
||||||
If only one candidate remains, use it; else continue to the next step.
|
If only one candidate remains, use it; else continue to the next step.
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.76 2003/10/22 22:28:10 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.77 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<sect1 id="xfunc">
|
<sect1 id="xfunc">
|
||||||
@ -2122,7 +2122,7 @@ CREATE OR REPLACE FUNCTION testpassbyval(integer, integer) RETURNS SETOF __testp
|
|||||||
of its arguments and the type it is expected to return. The routines are
|
of its arguments and the type it is expected to return. The routines are
|
||||||
called <literal>get_fn_expr_rettype(FmgrInfo *flinfo)</> and
|
called <literal>get_fn_expr_rettype(FmgrInfo *flinfo)</> and
|
||||||
<literal>get_fn_expr_argtype(FmgrInfo *flinfo, int argnum)</>.
|
<literal>get_fn_expr_argtype(FmgrInfo *flinfo, int argnum)</>.
|
||||||
They return the result or argument type OID, or InvalidOid if the
|
They return the result or argument type OID, or <symbol>InvalidOid</symbol> if the
|
||||||
information is not available.
|
information is not available.
|
||||||
The structure <literal>flinfo</> is normally accessed as
|
The structure <literal>flinfo</> is normally accessed as
|
||||||
<literal>fcinfo->flinfo</>. The parameter <literal>argnum</>
|
<literal>fcinfo->flinfo</>. The parameter <literal>argnum</>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.33 2003/10/21 23:28:42 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.34 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<sect1 id="xindex">
|
<sect1 id="xindex">
|
||||||
@ -431,7 +431,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.33 2003/10/21 23:28:42 tgl
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The least error-prone way to define a related set of comparison operators
|
The least error-prone way to define a related set of comparison operators
|
||||||
is to write the btree comparison support function first, and then write the
|
is to write the B-tree comparison support function first, and then write the
|
||||||
other functions as one-line wrappers around the support function. This
|
other functions as one-line wrappers around the support function. This
|
||||||
reduces the odds of getting inconsistent results for corner cases.
|
reduces the odds of getting inconsistent results for corner cases.
|
||||||
Following this approach, we first write
|
Following this approach, we first write
|
||||||
@ -600,15 +600,15 @@ CREATE OPERATOR CLASS complex_abs_ops
|
|||||||
<productname>PostgreSQL</productname> uses operator classes to infer the
|
<productname>PostgreSQL</productname> uses operator classes to infer the
|
||||||
properties of operators in more ways than just whether they can be used
|
properties of operators in more ways than just whether they can be used
|
||||||
with indexes. Therefore, you might want to create operator classes
|
with indexes. Therefore, you might want to create operator classes
|
||||||
even if you have no intention of indexing any columns of your datatype.
|
even if you have no intention of indexing any columns of your data type.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In particular, there are SQL features such as <literal>ORDER BY</> and
|
In particular, there are SQL features such as <literal>ORDER BY</> and
|
||||||
<literal>DISTINCT</> that require comparison and sorting of values.
|
<literal>DISTINCT</> that require comparison and sorting of values.
|
||||||
To implement these features on a user-defined datatype,
|
To implement these features on a user-defined data type,
|
||||||
<productname>PostgreSQL</productname> looks for the default B-tree operator
|
<productname>PostgreSQL</productname> looks for the default B-tree operator
|
||||||
class for the datatype. The <quote>equals</> member of this operator
|
class for the data type. The <quote>equals</> member of this operator
|
||||||
class defines the system's notion of equality of values for
|
class defines the system's notion of equality of values for
|
||||||
<literal>GROUP BY</> and <literal>DISTINCT</>, and the sort ordering
|
<literal>GROUP BY</> and <literal>DISTINCT</>, and the sort ordering
|
||||||
imposed by the operator class defines the default <literal>ORDER BY</>
|
imposed by the operator class defines the default <literal>ORDER BY</>
|
||||||
@ -621,16 +621,16 @@ CREATE OPERATOR CLASS complex_abs_ops
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If there is no default B-tree operator class for a datatype, the system
|
If there is no default B-tree operator class for a data type, the system
|
||||||
will look for a default hash operator class. But since that kind of
|
will look for a default hash operator class. But since that kind of
|
||||||
operator class only provides equality, in practice it is only enough
|
operator class only provides equality, in practice it is only enough
|
||||||
to support array equality.
|
to support array equality.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When there is no default operator class for a datatype, you will get
|
When there is no default operator class for a data type, you will get
|
||||||
errors like <quote>could not identify an ordering operator</> if you
|
errors like <quote>could not identify an ordering operator</> if you
|
||||||
try to use these SQL features with the datatype.
|
try to use these SQL features with the data type.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.28 2003/10/22 03:50:27 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.29 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<sect1 id="xoper">
|
<sect1 id="xoper">
|
||||||
@ -128,8 +128,8 @@ SELECT (a + b) AS c FROM test_complex;
|
|||||||
a WHERE clause like <literal>tab1.x = tab2.y</>, where <literal>tab1.x</>
|
a WHERE clause like <literal>tab1.x = tab2.y</>, where <literal>tab1.x</>
|
||||||
and <literal>tab2.y</> are of a user-defined type, and suppose that
|
and <literal>tab2.y</> are of a user-defined type, and suppose that
|
||||||
<literal>tab2.y</> is indexed. The optimizer cannot generate an
|
<literal>tab2.y</> is indexed. The optimizer cannot generate an
|
||||||
indexscan unless it can determine how to flip the clause around to
|
index scan unless it can determine how to flip the clause around to
|
||||||
<literal>tab2.y = tab1.x</>, because the indexscan machinery expects
|
<literal>tab2.y = tab1.x</>, because the index-scan machinery expects
|
||||||
to see the indexed column on the left of the operator it is given.
|
to see the indexed column on the left of the operator it is given.
|
||||||
<ProductName>PostgreSQL</ProductName> will <emphasis>not</> simply
|
<ProductName>PostgreSQL</ProductName> will <emphasis>not</> simply
|
||||||
assume that this is a valid transformation --- the creator of the
|
assume that this is a valid transformation --- the creator of the
|
||||||
@ -348,8 +348,8 @@ table1.column1 OP table2.column2
|
|||||||
the operator, since of course the referencing operator class couldn't
|
the operator, since of course the referencing operator class couldn't
|
||||||
exist yet. But attempts to use the operator in hash joins will fail
|
exist yet. But attempts to use the operator in hash joins will fail
|
||||||
at runtime if no such operator class exists. The system needs the
|
at runtime if no such operator class exists. The system needs the
|
||||||
operator class to find the datatype-specific hash function for the
|
operator class to find the data-type-specific hash function for the
|
||||||
operator's input datatype. Of course, you must also supply a suitable
|
operator's input data type. Of course, you must also supply a suitable
|
||||||
hash function before you can create the operator class.
|
hash function before you can create the operator class.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -370,7 +370,7 @@ table1.column1 OP table2.column2
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
The function underlying a hashjoinable operator must be marked
|
The function underlying a hash-joinable operator must be marked
|
||||||
immutable or stable. If it is volatile, the system will never
|
immutable or stable. If it is volatile, the system will never
|
||||||
attempt to use the operator for a hash join.
|
attempt to use the operator for a hash join.
|
||||||
</para>
|
</para>
|
||||||
@ -378,14 +378,14 @@ table1.column1 OP table2.column2
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
If a hashjoinable operator has an underlying function that is marked
|
If a hash-joinable operator has an underlying function that is marked
|
||||||
strict, the
|
strict, the
|
||||||
function must also be complete: that is, it should return TRUE or
|
function must also be complete: that is, it should return true or
|
||||||
FALSE, never NULL, for any two non-NULL inputs. If this rule is
|
false, never null, for any two nonnull inputs. If this rule is
|
||||||
not followed, hash-optimization of <literal>IN</> operations may
|
not followed, hash-optimization of <literal>IN</> operations may
|
||||||
generate wrong results. (Specifically, <literal>IN</> might return
|
generate wrong results. (Specifically, <literal>IN</> might return
|
||||||
FALSE where the correct answer per spec would be NULL; or it might
|
false where the correct answer according to the standard would be null; or it might
|
||||||
yield an error complaining that it wasn't prepared for a NULL result.)
|
yield an error complaining that it wasn't prepared for a null result.)
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
|
||||||
@ -488,7 +488,7 @@ table1.column1 OP table2.column2
|
|||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
The function underlying a mergejoinable operator must be marked
|
The function underlying a merge-joinable operator must be marked
|
||||||
immutable or stable. If it is volatile, the system will never
|
immutable or stable. If it is volatile, the system will never
|
||||||
attempt to use the operator for a merge join.
|
attempt to use the operator for a merge join.
|
||||||
</para>
|
</para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/xtypes.sgml,v 1.21 2003/10/21 22:51:14 tgl Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/xtypes.sgml,v 1.22 2003/11/01 01:56:29 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<sect1 id="xtypes">
|
<sect1 id="xtypes">
|
||||||
@ -131,7 +131,7 @@ complex_out(PG_FUNCTION_ARGS)
|
|||||||
Optionally, a user-defined type can provide binary input and output
|
Optionally, a user-defined type can provide binary input and output
|
||||||
routines. Binary I/O is normally faster but less portable than textual
|
routines. Binary I/O is normally faster but less portable than textual
|
||||||
I/O. As with textual I/O, it is up to you to define exactly what the
|
I/O. As with textual I/O, it is up to you to define exactly what the
|
||||||
external binary representation is. Most of the built-in datatypes
|
external binary representation is. Most of the built-in data types
|
||||||
try to provide a machine-independent binary representation. For
|
try to provide a machine-independent binary representation. For
|
||||||
<type>complex</type>, we will piggy-back on the binary I/O converters
|
<type>complex</type>, we will piggy-back on the binary I/O converters
|
||||||
for type <type>float8</>:
|
for type <type>float8</>:
|
||||||
@ -241,7 +241,7 @@ CREATE TYPE complex (
|
|||||||
the total length in bytes of the datum (including itself). The C
|
the total length in bytes of the datum (including itself). The C
|
||||||
functions operating on the data type must be careful to unpack any
|
functions operating on the data type must be careful to unpack any
|
||||||
toasted values they are handed (this detail can normally be hidden in the
|
toasted values they are handed (this detail can normally be hidden in the
|
||||||
GETARG macros). Then,
|
<function>GETARG</function> macros). Then,
|
||||||
when running the <command>CREATE TYPE</command> command, specify the
|
when running the <command>CREATE TYPE</command> command, specify the
|
||||||
internal length as <literal>variable</> and select the appropriate
|
internal length as <literal>variable</> and select the appropriate
|
||||||
storage option.
|
storage option.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user