rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Spell checking, consistent terminology.

This commit is contained in:
Peter Eisentraut 2003-11-01 01:56:29 +00:00
parent 4240d2bffd
commit 8442a92e5a
36 changed files with 877 additions and 870 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
doc/src/sgml/arch-dev.sgml
View File

@ -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">
@ -99,11 +99,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
<para>
The executor recursively steps through
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
<firstterm>storage system</firstterm> while scanning
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>
</step>
</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,
i.e. there is no parsing done in the <firstterm>frontend</firstterm> (client). The
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.
</para>
</sect1>
@ -297,9 +297,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
<itemizedlist>
<listitem>
<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
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
of the <productname>Berkeley Postgres</productname> project was
transformed into <productname>Postgres95</productname>.
@ -396,7 +396,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.22 2003/09/29 18:18:35 mo
<listitem>
<para>
<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,
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
@ -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
and loaded into a hash table, using its join attributes as hash keys.
Next the left relation is scanned and the
appropriate values of every tuple found are used as hash keys to
locate the matching tuples in the table.
appropriate values of every row found are used as hash keys to
locate the matching rows in the table.
</para>
</listitem>
</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>
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
aggregate-function calculation nodes. Most of these plan node
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
planner/optimizer and recursively processes it to extract the required set
of rows. This is essentially a demand-pull pipeline mechanism.
Each time a plan node is called, it must deliver one more tuple, or
report that it is done delivering tuples.
Each time a plan node is called, it must deliver one more row, or
report that it is done delivering rows.
</para>
<para>
To provide a concrete example, assume that the top
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
process the subplans (it starts with the subplan attached to
<literal>lefttree</literal>). The new top node (the top node of the left
subplan) is, let's say, a
<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.
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>
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
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 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.
@ -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
of the executor mechanism.) For <command>UPDATE</>, the planner arranges
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
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

12
doc/src/sgml/array.sgml
View File

@ -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">
<title>Arrays</title>
@ -348,9 +348,9 @@ SELECT ARRAY[5,6] || ARRAY[[1,2],[3,4]];
<para>
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
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
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>
SELECT array_dims(1 || ARRAY[2,3]);
array_dims
@ -368,9 +368,9 @@ SELECT array_dims(ARRAY[1,2] || 3);
<para>
When two arrays with an equal number of dimensions are concatenated, the
result retains the lower bound subscript of the lefthand operand's outer
dimension. The result is an array comprising every element of the lefthand
operand followed by every element of the righthand operand. For example:
result retains the lower bound subscript of the left-hand operand's outer
dimension. The result is an array comprising every element of the left-hand
operand followed by every element of the right-hand operand. For example:
<programlisting>
SELECT array_dims(ARRAY[1,2] || ARRAY[3,4,5]);
array_dims

28
doc/src/sgml/catalogs.sgml
View File

@ -1,6 +1,6 @@
<!--
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">
@ -755,9 +755,9 @@
<entry><type>int4</type></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
within the tuple.
within the row.
</entry>
</row>
@ -800,9 +800,9 @@
<entry></entry>
<entry>
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> 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
the set. So the <structfield>atttypid</structfield> (see
above) refers to the type returned by this query, but the
@ -1046,7 +1046,7 @@
<entry><type>float4</type></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.
It is updated by <command>VACUUM</command>,
<command>ANALYZE</command>, and <command>CREATE INDEX</command>.
@ -1553,7 +1553,7 @@
<entry><type>xid</type></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.
This is used to determine when commit-log space can be recycled.
</entry>
@ -1564,7 +1564,7 @@
<entry><type>xid</type></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
database. This is useful to check whether a database must be vacuumed
soon to avoid transaction ID wrap-around problems.
@ -1666,7 +1666,7 @@
<row>
<entry><structfield>refobjid</structfield></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>
</row>
@ -1945,7 +1945,7 @@
<row>
<entry><structfield>indkey</structfield></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>
This is an array of <structfield>indnatts</structfield> (up to
<symbol>INDEX_MAX_KEYS</symbol>) values that indicate which
@ -2407,7 +2407,7 @@
<entry><structfield>opcamid</structfield></entry>
<entry><type>oid</type></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>
@ -3534,7 +3534,7 @@
For types used in system tables, it is critical that the size
and alignment defined in <structname>pg_type</structname>
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>
</note></entry>
</row>
@ -3611,8 +3611,8 @@
<entry></entry>
<entry><para>
<structfield>typndims</structfield> is the number of array dimensions
for a domain that is an array (that is, typbasetype is an array type;
the domain's typelem will match the base type's typelem).
for a domain that is an array (that is, <structfield>typbasetype</> is an array type;
the domain's <structfield>typelem</> will match the base type's <structfield>typelem</structfield>).
Zero for types other than array domains.
</para></entry>
</row>

38
doc/src/sgml/datatype.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.127 2003/10/22 18:10:53 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.128 2003/11/01 01:56:29 petere Exp $
-->
<chapter id="datatype">
@ -1350,10 +1350,10 @@ SELECT b, char_length(b) FROM test2;
<para>
When <type>timestamp</> values are stored as double precision floating-point
numbers (currently the default), the effective limit of precision
may be less than 6. Timestamp values are stored as seconds
may be less than 6. <type>timestamp</type> values are stored as seconds
since 2000-01-01, and microsecond precision is achieved for dates within
a few years of 2000-01-01, but the precision degrades for dates further
away. When timestamps are stored as eight-byte integers (a compile-time
away. When <type>timestamp</type> values are stored as eight-byte integers (a compile-time
option), microsecond precision is available over the full range of
values. However eight-byte integer timestamps have a reduced range of
dates from 4713 BC up to 294276 AD.
@ -1460,7 +1460,7 @@ SELECT b, char_length(b) FROM test2;
<tbody>
<row>
<entry>January 8, 1999</entry>
<entry>unambiguous in any datestyle input mode</entry>
<entry>unambiguous in any <varname>datestyle</varname> input mode</entry>
</row>
<row>
<entry>1999-01-08</entry>
@ -1574,23 +1574,23 @@ SELECT b, char_length(b) FROM test2;
<entry>same as 16:05; input hour must be <= 12</entry>
</row>
<row>
<entry>04:05:06.789-8</entry>
<entry><literal>04:05:06.789-8</literal></entry>
<entry>ISO 8601</entry>
</row>
<row>
<entry>04:05:06-08:00</entry>
<entry><literal>04:05:06-08:00</literal></entry>
<entry>ISO 8601</entry>
</row>
<row>
<entry>04:05-08:00</entry>
<entry><literal>04:05-08:00</literal></entry>
<entry>ISO 8601</entry>
</row>
<row>
<entry>040506-08</entry>
<entry><literal>040506-08</literal></entry>
<entry>ISO 8601</entry>
</row>
<row>
<entry>04:05:06 PST</entry>
<entry><literal>04:05:06 PST</literal></entry>
<entry>time zone specified by name</entry>
</row>
</tbody>
@ -1608,28 +1608,28 @@ SELECT b, char_length(b) FROM test2;
</thead>
<tbody>
<row>
<entry>PST</entry>
<entry><literal>PST</literal></entry>
<entry>Pacific Standard Time</entry>
</row>
<row>
<entry>-8:00</entry>
<entry><literal>-8:00</literal></entry>
<entry>ISO-8601 offset for PST</entry>
</row>
<row>
<entry>-800</entry>
<entry><literal>-800</literal></entry>
<entry>ISO-8601 offset for PST</entry>
</row>
<row>
<entry>-8</entry>
<entry><literal>-8</literal></entry>
<entry>ISO-8601 offset for PST</entry>
</row>
<row>
<entry>zulu</entry>
<entry><literal>zulu</literal></entry>
<entry>Military abbreviation for GMT</entry>
</row>
<row>
<entry>z</entry>
<entry>Short form of zulu</entry>
<entry><literal>z</literal></entry>
<entry>Short form of <literal>zulu</literal></entry>
</row>
</tbody>
</tgroup>
@ -1923,7 +1923,7 @@ January 8 04:05:06 1999 PST
<tgroup cols="3">
<thead>
<row>
<entry>DateStyle setting</entry>
<entry><varname>datestyle</varname> Setting</entry>
<entry>Input Ordering</entry>
<entry>Example Output</entry>
</row>
@ -3026,10 +3026,10 @@ SELECT * FROM test;
<para>
A final identifier type used by the system is <type>tid</>, or tuple
identifier. This is the data type of the system column
identifier (row identifier). This is the data type of the system column
<structfield>ctid</>. A tuple ID is a pair
(block number, tuple index within block) that identifies the
physical location of the tuple within its table.
physical location of the row within its table.
</para>
<para>

20
doc/src/sgml/ddl.sgml
View File

@ -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">
<title>Data Definition</title>
@ -230,9 +230,9 @@ DROP TABLE products;
<para>
The identity (transaction ID) of the inserting transaction for
this tuple. (Note: In this context, a tuple is an individual
state of a row; each update of a row creates a new tuple for the
same logical row.)
this row version. (A row version is an individual state of a
row; each update of a row creates a new row version for the same
logical row.)
</para>
</listitem>
</varlistentry>
@ -260,8 +260,8 @@ DROP TABLE products;
<para>
The identity (transaction ID) of the deleting transaction, or
zero for an undeleted tuple. It is possible for this column to
be nonzero in a visible tuple: That usually indicates that the
zero for an undeleted row version. It is possible for this column to
be nonzero in a visible row version: That usually indicates that the
deleting transaction hasn't committed yet, or that an attempted
deletion was rolled back.
</para>
@ -289,9 +289,9 @@ DROP TABLE products;
</indexterm>
<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
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
updated or moved by <command>VACUUM FULL</>. Therefore
<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
within a single transaction. In practice this limit is not a
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>
</sect1>
@ -1047,7 +1047,7 @@ SELECT name, altitude
</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
<structfield>TABLEOID</structfield> in each table which can tell you the
originating table:

4
doc/src/sgml/func.sgml
View File

@ -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
-->
@ -4869,7 +4869,7 @@ substring('foobar' from 'o(.)b') <lineannotation>o</lineannotation>
</table>
<para>
In addition to these functions, the SQL <literal>OVERLAPS</> keyword is
In addition to these functions, the SQL <literal>OVERLAPS</> operator is
supported:
<synopsis>
( <replaceable>start1</replaceable>, <replaceable>end1</replaceable> ) OVERLAPS ( <replaceable>start2</replaceable>, <replaceable>end2</replaceable> )

26
doc/src/sgml/indexcost.sgml
View File

@ -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">
@ -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
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
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
work of the cost estimator can be done by calling standard routines
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
<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
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).
In addition, an appropriate multiple of cpu_operator_cost should be charged
for any comparison operators invoked during index processing (especially
@ -167,27 +167,27 @@ amcostestimate (Query *root,
<para>
The access costs should include all disk and CPU costs associated with
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>
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
to set it nonzero.
</para>
<para>
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
tuples that actually pass the given qual conditions.
rows that actually pass the given qual conditions.
</para>
<para>
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
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.
</para>
@ -199,7 +199,7 @@ amcostestimate (Query *root,
<step>
<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
knowledge, use the standard optimizer function <function>clauselist_selectivity()</function>:
@ -212,10 +212,10 @@ amcostestimate (Query *root,
<step>
<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
the number of tuples in the index, but it might be more. (Note that the
index's size in pages and tuples is available from the IndexOptInfo struct.)
the number of rows in the index, but it might be more. (Note that the
index's size in pages and rows is available from the IndexOptInfo struct.)
</para>
</step>
@ -234,7 +234,7 @@ amcostestimate (Query *root,
/*
* Our generic assumption is that the index pages will be read
* 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.
*/
cost_qual_eval(&amp;index_qual_cost, indexQuals);

7
doc/src/sgml/installation.sgml
View File

@ -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">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
@ -915,8 +915,9 @@ JAVACMD=$JAVA_HOME/bin/java
<term><option>--enable-thread-safety</option></term>
<listitem>
<para>
Allow separate libpq and ecpg threads to safely control their
private connection handles.
Allow separate threads in <application>libpq</application>
and <application>ECPG</application> programs to safely
control their private connection handles.
</para>
</listitem>
</varlistentry>

34
doc/src/sgml/jdbc.sgml
View File

@ -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">
@ -572,7 +572,7 @@ st.close();
<sect1 id="jdbc-callproc">
<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
functions.</para>
@ -636,7 +636,7 @@ upperProc.close();
<para>When calling a function that returns
a <type>refcursor</type> you must cast the return type
of getObject to
of <function>getObject</function> to
a <classname>ResultSet</classname></para>
<programlisting>
@ -953,7 +953,7 @@ ps.close();
<para>
<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
these are facilities unique to <productname>PostgreSQL</productname>,
we support them from Java, with a set of extension
@ -999,7 +999,7 @@ public class PGConnection
public Fastpath getFastpathAPI() throws SQLException
</synopsis>
<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
<acronym>API</acronym>.
</para>
@ -1017,15 +1017,15 @@ Fastpath fp = ((org.postgresql.PGConnection)myconn).getFastpathAPI();
<formalpara>
<title>Returns:</title>
<para>
Fastpath object allowing access to functions on the
<productname>PostgreSQL</productname> backend.
<classname>Fastpath</> object allowing access to functions on the
<productname>PostgreSQL</productname> server.
</para>
</formalpara>
<formalpara>
<title>Throws:</title>
<para>
<classname>SQLException</> by Fastpath when initializing for first time
<classname>SQLException</> by <classname>Fastpath</> when initializing for first time
</para>
</formalpara>
</listitem>
@ -1110,7 +1110,7 @@ java.lang.Object
<para>
<classname>Fastpath</classname> is an <acronym>API</acronym> that
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
Large Object <acronym>API</acronym> uses it.
</para>
@ -1134,7 +1134,7 @@ Fastpath fp = ((org.postgresql.PGConnection)conn).getFastpathAPI();
the <function>getFastpathAPI()</function> is an extension method,
not part of <acronym>JDBC</acronym>. Once you have a
<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.
</para>
@ -1156,7 +1156,7 @@ public Object fastpath(int fnid,
FastpathArg args[]) throws SQLException
</synopsis>
<para>
Send a function call to the <productname>PostgreSQL</productname> backend.
Send a function call to the <productname>PostgreSQL</productname> server.
</para>
<formalpara>
@ -1166,7 +1166,7 @@ public Object fastpath(int fnid,
<parameter>resulttype</> - True if the result is an integer, false
for
other results
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fastpath
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fast-path call
</para>
</formalpara>
@ -1186,7 +1186,7 @@ public Object fastpath(String name,
FastpathArg args[]) throws SQLException
</synopsis>
<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>
<note>
@ -1194,7 +1194,7 @@ public Object fastpath(String name,
The mapping for the procedure name to function id needs to
exist, usually to an earlier call to <function>addfunction()</function>. This is
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
</para>
</note>
@ -1206,7 +1206,7 @@ public Object fastpath(String name,
<parameter>resulttype</> - True if the result is an integer, false
for
other results
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fastpath
<parameter>args</> - <classname>FastpathArguments</classname> to pass to fast-path call
</para>
</formalpara>
@ -1381,7 +1381,7 @@ java.lang.Object
</synopsis>
<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
implements methods needed to provide this capability.
</para>
@ -1700,7 +1700,7 @@ java.lang.Object
Cloneable
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.
Variables

60
doc/src/sgml/libpq.sgml
View File

@ -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">
@ -307,7 +307,7 @@ PGconn *PQsetdbLogin(const char *pghost,
<para>
This is the predecessor of <function>PQconnectdb</function> with a fixed
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.
</para>
</listitem>
@ -849,7 +849,7 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
Certain parameter values are reported by the server automatically at
connection startup or whenever their values change.
<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.
</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.
The 3.0 protocol will normally be used when communicating with
<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>
</listitem>
</varlistentry>
@ -1071,23 +1071,23 @@ as <literal>$1</>, <literal>$2</>, etc.
<parameter>nParams</> is the number of parameters supplied; it is the length
of the arrays <parameter>paramTypes[]</>, <parameter>paramValues[]</>,
<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 data types to be assigned to
the parameter symbols. If <parameter>paramTypes</> is NULL, or any particular
element in the array is zero, the backend assigns a datatype to the parameter
the parameter symbols. If <parameter>paramTypes</> is <symbol>NULL</symbol>, or any particular
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.
<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
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).
<parameter>paramLengths[]</> specifies the actual data lengths of
binary-format parameters. It is ignored for NULL parameters and text-format
parameters. The array pointer may be NULL when there are no binary
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.
<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
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
obtain results in binary format. (There is not currently a provision to
obtain different result columns in different formats, although that is
@ -1544,7 +1544,7 @@ char *PQfname(const PGresult *res,
</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>
</listitem>
</varlistentry>
@ -1768,8 +1768,8 @@ the value is likely to contain embedded nulls.)
</para>
<para>
An empty string is returned if the field value is NULL. See
<function>PQgetisnull</> to distinguish NULLs from empty-string values.
An empty string is returned if the field value is null. See
<function>PQgetisnull</> to distinguish null values from empty-string values.
</para>
<para>
@ -2123,7 +2123,7 @@ void PQfreemem(void *ptr);
<function>PQunescapeBytea</function>,
and <function>PQnotifies</function>.
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()</>.
</para>
</listitem>
@ -2547,7 +2547,7 @@ typedef struct {
parameters to be passed to the function; they must match the declared
function argument list. When the <parameter>isint</> field of a
parameter
struct is true,
structure is true,
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
byte-swapping occurs. When <parameter>isint</> is false, the
@ -2577,7 +2577,7 @@ caller is responsible for freeing the <structname>PGresult</structname> with
</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.
</para>
@ -2646,8 +2646,8 @@ do not represent separate allocations.
<note>
<para>
In <productname>PostgreSQL</productname> 6.4 and later,
the <structfield>be_pid</structfield> is that of the notifying backend process,
whereas in earlier versions it was always the <acronym>PID</acronym> of your own 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 server process.
</para>
</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
commands, the application must continue fetching results via
<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
safe to issue more commands.
</para>
@ -2816,14 +2816,14 @@ int PQputCopyData(PGconn *conn,
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,
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
value is -1. If the value is zero, wait for write-ready and try again.)
</para>
<para>
The application may divide the COPY datastream into bufferloads of any
convenient size. Bufferload boundaries have no semantic significance when
The application may divide the <command>COPY</command> data stream into buffer loads of any
convenient size. Buffer-load boundaries have no semantic significance when
sending. The contents of the data stream must match the data format expected
by the <command>COPY</> command; see
<xref linkend="sql-copy" endterm="sql-copy-title"> for details.
@ -2844,7 +2844,7 @@ int PQputCopyEnd(PGconn *conn,
<para>
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</>
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
@ -2855,7 +2855,7 @@ option to force failure does not work when using pre-3.0-protocol connections.)
<para>
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
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
value is -1. If the value is zero, wait for write-ready and try again.)
</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
is available, it is not returned. Successful return of a data row
involves allocating a chunk of memory to hold the data. The
<parameter>buffer</> parameter must be non-NULL. <parameter>*buffer</>
is set to point to the allocated memory, or to NULL in cases where no
buffer is returned. A non-NULL result buffer must be freed using
<parameter>buffer</> parameter must be non-<symbol>NULL</symbol>. <parameter>*buffer</>
is set to point to the allocated memory, or to <symbol>NULL</symbol> in cases where no
buffer is returned. A non-<symbol>NULL</symbol> result buffer must be freed using
<function>PQfreemem</> when no longer needed.
</para>
@ -3053,7 +3053,7 @@ int PQputline(PGconn *conn,
</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>PQgetlineAsync</function>, except that applications are not
obliged to send exactly one data row per <function>PQputline</function>

2
doc/src/sgml/lobj.sgml
View File

@ -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">

53
doc/src/sgml/maintenance.sgml
View File

@ -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">
@ -101,13 +101,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
<para>
In normal <productname>PostgreSQL</productname> operation, an
<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
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
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
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</>.
</para>
@ -125,7 +125,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
<para>
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
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
return disk space to the operating system. If you need to return disk
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>
<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
more aggressive approach.
</para>
@ -242,7 +242,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.26 2003/10/09 19:05:09
<para>
<productname>PostgreSQL</productname>'s MVCC transaction semantics
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
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
@ -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
<quote>older</> and two billion that are <quote>newer</>; another
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
normal XID, the tuple will appear to be <quote>in the past</> for
endpoint. Therefore, once a row version has been created with a particular
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
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
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
two-billion-transactions-old mark. Once they are assigned this
special XID, they will appear to be <quote>in the past</> to all
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</>.
</para>
<para>
<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
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,
the maximum safe interval between <command>VACUUM</> runs on any table
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
into the future --- i.e., is lost to you. (Of course, it'll reappear
after another two billion transactions, but that's no help.)
@ -355,10 +355,10 @@ VACUUM
<para>
<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
<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
modified in any way, it will not need subsequent vacuuming to avoid
transaction ID wraparound problems. This technique is used by
@ -422,13 +422,16 @@ VACUUM
<para>
The simplest production-grade approach to managing log output is to
send it all to <application>syslog</> and let <application>syslog</>
deal with file rotation. To do this, set the configurations parameter
<literal>syslog</> to 2 (to log to <application>syslog</> only) in
<filename>postgresql.conf</>. Then you can send a <literal>SIGHUP</literal>
signal to the <application>syslog</> daemon whenever you want to force it
to start writing a new log file. If you want to automate log rotation,
the logrotate program can be configured to work with log files from syslog.
send it all to <application>syslog</> and let
<application>syslog</> deal with file rotation. To do this, set the
configurations parameter <literal>syslog</> to 2 (to log to
<application>syslog</> only) in <filename>postgresql.conf</>. Then
you can send a <literal>SIGHUP</literal> signal to the
<application>syslog</> daemon whenever you want to force it to
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>

24
doc/src/sgml/monitoring.sgml
View File

@ -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">
@ -237,8 +237,8 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<row>
<entry><structname>pg_stat_all_tables</></entry>
<entry>For each table in the current database, total numbers of
sequential and index scans, total numbers of tuples returned by
each type of scan, and totals of tuple insertions, updates,
sequential and index scans, total numbers of rows returned by
each type of scan, and totals of row insertions, updates,
and deletions.</entry>
</row>
@ -257,9 +257,9 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<row>
<entry><structname>pg_stat_all_indexes</></entry>
<entry>For each index in the current database, the total number
of index scans that have used that index, the number of index tuples
read, and the number of successfully fetched heap tuples. (This may
be less when there are index entries pointing to expired heap tuples.)
of index scans that have used that index, the number of index rows
read, and the number of successfully fetched heap rows. (This may
be less when there are index entries pointing to expired heap rows.)
</entry>
</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><type>bigint</type></entry>
<entry>
Number of tuples read by sequential scans when argument is a table,
or number of index tuples read when argument is an index
Number of rows read by sequential scans when argument is a table,
or number of index rows read when argument is an index
</entry>
</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><type>bigint</type></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 an index
</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><type>bigint</type></entry>
<entry>
Number of tuples inserted into table
Number of rows inserted into table
</entry>
</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><type>bigint</type></entry>
<entry>
Number of tuples updated in table
Number of rows updated in table
</entry>
</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><type>bigint</type></entry>
<entry>
Number of tuples deleted from table
Number of rows deleted from table
</entry>
</row>

14
doc/src/sgml/nls.sgml
View File

@ -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">
@ -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
your translated messages. When you configure your source tree, be
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
anyway. To try out your work, follow the applicable portions of
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
use a packaged source distribution, you won't 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>
@ -374,7 +374,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
<variablelist>
<varlistentry>
<term>CATALOG_NAME</term>
<term><varname>CATALOG_NAME</varname></term>
<listitem>
<para>
@ -385,7 +385,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
</varlistentry>
<varlistentry>
<term>AVAIL_LANGUAGES</term>
<term><varname>AVAIL_LANGUAGES</varname></term>
<listitem>
<para>
@ -395,7 +395,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
</varlistentry>
<varlistentry>
<term>GETTEXT_FILES</term>
<term><varname>GETTEXT_FILES</varname></term>
<listitem>
<para>
@ -411,7 +411,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
</varlistentry>
<varlistentry>
<term>GETTEXT_TRIGGERS</term>
<term><varname>GETTEXT_TRIGGERS</varname></term>
<listitem>
<para>

16
doc/src/sgml/page.sgml
View File

@ -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">
@ -27,7 +27,7 @@ In the following explanation, a
is assumed to contain 8 bits. In addition, the term
<firstterm>item</firstterm>
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>
@ -65,7 +65,7 @@ free space pointers.</entry>
<row>
<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>
@ -162,7 +162,7 @@ data. Empty in ordinary tables.</entry>
and a version indicator. Beginning with
<productname>PostgreSQL</productname> 7.3 the version number is 1; prior
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
more than one page size in an installation.
</para>
@ -209,12 +209,12 @@ data. Empty in ordinary tables.</entry>
<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
bitmap, an optional object ID field, and the user data. The header is
detailed
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
distance for the platform.
The null bitmap is
@ -274,13 +274,13 @@ data. Empty in ordinary tables.</entry>
<entry>t_xvac</entry>
<entry>TransactionId</entry>
<entry>4 bytes</entry>
<entry>XID for VACUUM operation moving tuple</entry>
<entry>XID for VACUUM operation moving row version</entry>
</row>
<row>
<entry>t_ctid</entry>
<entry>ItemPointerData</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>
<entry>t_natts</entry>

2
doc/src/sgml/perform.sgml
View File

@ -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">

4
doc/src/sgml/plpgsql.sgml
View File

@ -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">
@ -180,7 +180,7 @@ END;
</sect2>
<sect2 id="plpgsql-args-results">
<title>Supported Argument and Result Datatypes</title>
<title>Supported Argument and Result Data Types</title>
<para>
Functions written in <application>PL/pgSQL</application> can accept

8
doc/src/sgml/protocol.sgml
View File

@ -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">
<title>Frontend/Backend Protocol</title>
@ -995,7 +995,7 @@
<command>SET</> SQL command executed by the frontend, and this case
is effectively synchronous --- but it is also possible for parameter
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
to report the current effective value.
</para>
@ -1450,7 +1450,7 @@ AuthenticationCleartextPassword (B)
</Term>
<ListItem>
<Para>
Specifies that a cleartext password is required.
Specifies that a clear-text password is required.
</Para>
</ListItem>
</VarListEntry>
@ -2126,7 +2126,7 @@ CopyData (F &amp; B)
</Term>
<ListItem>
<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,
but messages sent by frontends may divide the data stream
arbitrarily.

4
doc/src/sgml/queries.sgml
View File

@ -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">
<title>Queries</title>
@ -1244,7 +1244,7 @@ SELECT a AS b FROM table1 ORDER BY a;
determined with the <literal>&gt;</literal> operator.
<footnote>
<para>
Actually, <productname>PostgreSQL</> uses the <firstterm>default btree
Actually, <productname>PostgreSQL</> uses the <firstterm>default B-tree
operator class</> for the column's data type to determine the sort
ordering for <literal>ASC</> and <literal>DESC</>. Conventionally,
data types will be set up so that the <literal>&lt;</literal> and

2
doc/src/sgml/query.sgml
View File

@ -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">

75
doc/src/sgml/ref/alter_sequence.sgml
View File

@ -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
-->
@ -58,42 +58,43 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<term><replaceable class="parameter">increment</replaceable></term>
<listitem>
<para>
The
<option>INCREMENT BY <replaceable class="parameter">increment</replaceable></option>
clause is optional. A positive value will make an
ascending sequence, a negative one a descending sequence.
If unspecified, the old increment value will be maintained.
The clause <literal>INCREMENT BY <replaceable
class="parameter">increment</replaceable></literal> is
optional. A positive value will make an ascending sequence, a
negative one a descending sequence. If unspecified, the old
increment value will be maintained.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">minvalue</replaceable></term>
<term>NO MINVALUE</term>
<term><literal>NO MINVALUE</literal></term>
<listitem>
<para>
The optional clause <option>MINVALUE
<replaceable class="parameter">minvalue</replaceable></option>
determines the minimum value
a sequence can generate. If <option>NO MINVALUE</option> is specified,
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
value will be maintained.
The optional clause <literal>MINVALUE <replaceable
class="parameter">minvalue</replaceable></literal> determines
the minimum value a sequence can generate. If <literal>NO
MINVALUE</literal> is specified, the defaults of 1 and
-2<superscript>63</>-1 for ascending and descending sequences,
respectively, will be used. If neither option is specified,
the current minimum value will be maintained.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">maxvalue</replaceable></term>
<term>NO MAXVALUE</term>
<term><literal>NO MAXVALUE</literal></term>
<listitem>
<para>
The optional clause <option>MAXVALUE
<replaceable class="parameter">maxvalue</replaceable></option>
determines the maximum value for the sequence. If
<option>NO MAXVALUE</option> is specified, the defaults are 2^63-1 and -1 for
ascending and descending sequences, respectively, will be used. If
neither option is specified, the current maximum value will be
maintained.
The optional clause <literal>MAXVALUE <replaceable
class="parameter">maxvalue</replaceable></literal> determines
the maximum value for the sequence. If <literal>NO
MAXVALUE</literal> is specified, the defaults are
2<superscript>63</>-1 and -1 for ascending and descending
sequences, respectively, will be used. If neither option is
specified, the current maximum value will be maintained.
</para>
</listitem>
</varlistentry>
@ -102,9 +103,9 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<term><replaceable class="parameter">start</replaceable></term>
<listitem>
<para>
The optional <option>RESTART WITH
<replaceable class="parameter">start</replaceable></option>
clause changes the current value of the sequence.
The optional clause <literal>RESTART WITH <replaceable
class="parameter">start</replaceable></literal> changes the
current value of the sequence.
</para>
</listitem>
</varlistentry>
@ -113,11 +114,12 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<term><replaceable class="parameter">cache</replaceable></term>
<listitem>
<para>
The <option>CACHE <replaceable class="parameter">cache</replaceable></option> option
enables sequence numbers to be preallocated
and stored in memory for faster access. The minimum
value is 1 (only one value can be generated at a time, i.e., no cache).
If unspecified, the old cache value will be maintained.
The clause <literal>CACHE <replaceable
class="parameter">cache</replaceable></literal> enables
sequence numbers to be preallocated and stored in memory for
faster access. The minimum value is 1 (only one value can be
generated at a time, i.e., no cache). If unspecified, the old
cache value will be maintained.
</para>
</listitem>
</varlistentry>
@ -126,7 +128,7 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<term>CYCLE</term>
<listitem>
<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
<replaceable class="parameter">maxvalue</replaceable> or
<replaceable class="parameter">minvalue</replaceable> has been
@ -144,11 +146,12 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<term>NO CYCLE</term>
<listitem>
<para>
If the optional <option>NO CYCLE</option> keyword is specified, any
calls to <function>nextval</function> after the sequence has reached
its maximum value will return an error. If neither
<option>CYCLE</option> or <option>NO CYCLE</option> are specified,
the old cycle behaviour will be maintained.
If the optional <literal>NO CYCLE</literal> key word is
specified, any calls to <function>nextval</function> after the
sequence has reached its maximum value will return an error.
If neither <literal>CYCLE</literal> or <literal>NO
CYCLE</literal> are specified, the old cycle behaviour will be
maintained.
</para>
</listitem>
</varlistentry>
@ -161,10 +164,10 @@ ALTER SEQUENCE <replaceable class="parameter">name</replaceable> [ INCREMENT [ B
<para>
Restart a sequence called <literal>serial</literal>, at 105:
</para>
<programlisting>
ALTER SEQUENCE serial RESTART WITH 105;
</programlisting>
</para>
</refsect1>
<refsect1>

4
doc/src/sgml/ref/create_table.sgml
View File

@ -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
-->
@ -183,7 +183,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
<para>
The <literal>LIKE</literal> clause specifies a table from which
the new table automatically inherits all column names, their data types, and
<literal>NOT NULL</literal> constraints.
not-null constraints.
</para>
<para>
Unlike <literal>INHERITS</literal>, the new table and inherited table

4
doc/src/sgml/ref/create_type.sgml
View File

@ -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
-->
@ -124,7 +124,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable> (
The receive function may be declared as taking one argument of 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.
(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
element type in case this is an array type.) Similarly, the optional
<replaceable class="parameter">send_function</replaceable> converts

2
doc/src/sgml/ref/create_view.sgml
View File

@ -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
-->

6
doc/src/sgml/ref/pg_ctl-ref.sgml
View File

@ -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
-->
@ -220,8 +220,8 @@ PostgreSQL documentation
shutdown is indicated by removal of the <acronym>PID</acronym>
file. For starting up, a successful <command>psql -l</command>
indicates success. <command>pg_ctl</command> will attempt to
use the proper port for psql. If the environment variable
PGPORT exists, that is used. Otherwise, it will see if a port
use the proper port for <application>psql</>. If the environment variable
<envar>PGPORT</envar> exists, that is used. Otherwise, it will see if a port
has been set in the <filename>postgresql.conf</filename> file.
If neither of those is used, it will use the default port that
<productname>PostgreSQL</productname> was compiled with

4
doc/src/sgml/ref/psql-ref.sgml
View File

@ -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
-->
@ -96,7 +96,7 @@ PostgreSQL documentation
processed in a single transaction, unless there are explicit
BEGIN/COMMIT commands included in the string to divide it into
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>
</listitem>
</varlistentry>

2
doc/src/sgml/ref/select.sgml
View File

@ -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
-->

28
doc/src/sgml/release.sgml
View File

@ -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">
@ -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
if at the beginning/end of the cursor</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.
</para>
</listitem>
@ -2739,7 +2739,7 @@ AIX, MSWIN, VAX, N32K fixes (Tom)
Multibytes fixes (Tom)
Unicode fixes (Tatsuo)
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)
ODBC fixes (Hiroshi)
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)
Require cursor FETCH to honor LIMIT (Tom)
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)
Make ALTER/DROP TABLE rollback-able (Vadim, Tom)
Store initdb collation in pg_control so collation cannot be changed (Tom)
@ -3104,8 +3104,8 @@ Fix for mergejoin plans (Tom)
Fix TRUNCATE failure on relations with indexes (Tom)
Avoid database-wide restart on write error (Hiroshi)
Fix nodeMaterial to honor chgParam by recomputing its output (Tom)
Fix VACUUM problem with moving chain of update tuples when source and
destination of a tuple lie on the same page (Tom)
Fix VACUUM problem with moving chain of update row versions when source
and destination of a row version lie on the same page (Tom)
Fix user.c CommandCounterIncrement (Tom)
Fix for AM/PM boundary problem in to_char() (Karel Zak)
Fix TIME aggregate handling (Tom)
@ -3822,7 +3822,7 @@ ACL file descriptor leak fix(Atsushi Ogawa)
New expresssion subtree code(Tom)
Avoid disk writes for read-only transactions(Vadim)
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
Allow port numbers 32k - 64k(Bruce)
Add ^ precidence(Bruce)
@ -5234,13 +5234,13 @@ Check for geometric intersections at endpoints to avoid rounding ugliness(Thomas
Catch non-functional delete attempts(Vadim)
Change time function names to be more consistent(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
updated tuples, etc)(Vadim)
updated rows, etc.)(Vadim)
Fix for SELECT null, 'fail' FROM pg_am (Patrick)
SELECT NULL as EMPTY_FIELD now allowed(Patrick)
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 handling of functions with non-attribute first argument in
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)
Added JDBC driver as an interface(Adrian & Peter)
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)
SPI (Server Programming Interface) allows execution of queries inside
C-functions (Vadim)
@ -5481,7 +5481,7 @@ fix local buffers leak in transaction aborts (Vadim)
fix file manager memmory leaks, cleanups (Vadim, Massimo)
fix storage manager memmory leaks (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)
many psql, pg_dump, and libpq memory leaks fixed using Purify (Igor)
@ -6180,7 +6180,7 @@ Bug fixes:
* 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. 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
* the LISTEN/NOTIFY asynchronous notification mechanism now work
* NOTIFY in rule action bodies now work
@ -6206,7 +6206,7 @@ Other changes and enhancements:
libpgtcl changes:
* 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 "".
* the large object interface is available as pg_lo* tcl commands:
pg_lo_open, pg_lo_close, pg_lo_creat, etc.

4
doc/src/sgml/rules.sgml
View File

@ -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">
<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
is why <command>ROLLBACK</command> is fast. In an <command>UPDATE</command>,
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
<literal>xmax</> entries are set to the current command counter
and current transaction ID. Thus the old row is hidden, and after

12
doc/src/sgml/runtime.sgml
View File

@ -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">
@ -878,9 +878,9 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
Specifies the maximum amount of memory to be used by
<command>VACUUM</command> to keep track of to-be-reclaimed
tuples. The value is specified in kilobytes, and defaults to
8192 kilobytes. Larger settings may improve the speed of
vacuuming large tables that have many deleted tuples.
rows. The value is specified in kilobytes, and defaults to
8192 kB. Larger settings may improve the speed of
vacuuming large tables that have many deleted rows.
</para>
</listitem>
</varlistentry>
@ -1333,7 +1333,7 @@ SET ENABLE_SEQSCAN TO OFF;
<listitem>
<para>
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.
</para>
</listitem>
@ -1344,7 +1344,7 @@ SET ENABLE_SEQSCAN TO OFF;
<listitem>
<para>
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
is 0.001.
</para>

6
doc/src/sgml/syntax.sgml
View File

@ -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">
@ -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}
(1 row)
</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
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.
</para>

2
doc/src/sgml/typeconv.sgml
View File

@ -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">

4
doc/src/sgml/xfunc.sgml
View File

@ -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">
@ -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
called <literal>get_fn_expr_rettype(FmgrInfo *flinfo)</> and
<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.
The structure <literal>flinfo</> is normally accessed as
<literal>fcinfo-&gt;flinfo</>. The parameter <literal>argnum</>

4
doc/src/sgml/xindex.sgml
View File

@ -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">
@ -431,7 +431,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.33 2003/10/21 23:28:42 tgl
<para>
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
reduces the odds of getting inconsistent results for corner cases.
Following this approach, we first write

20
doc/src/sgml/xoper.sgml
View File

@ -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">
@ -129,7 +129,7 @@ SELECT (a + b) AS c FROM test_complex;
and <literal>tab2.y</> are of a user-defined type, and suppose that
<literal>tab2.y</> is indexed. The optimizer cannot generate an
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.
<ProductName>PostgreSQL</ProductName> will <emphasis>not</> simply
assume that this is a valid transformation --- the creator of the
@ -348,7 +348,7 @@ table1.column1 OP table2.column2
the operator, since of course the referencing operator class couldn't
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
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 data type. Of course, you must also supply a suitable
hash function before you can create the operator class.
</para>
@ -370,7 +370,7 @@ table1.column1 OP table2.column2
<note>
<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
attempt to use the operator for a hash join.
</para>
@ -378,14 +378,14 @@ table1.column1 OP table2.column2
<note>
<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
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
function must also be complete: that is, it should return true or
false, never null, for any two nonnull inputs. If this rule is
not followed, hash-optimization of <literal>IN</> operations may
generate wrong results. (Specifically, <literal>IN</> might return
FALSE where the correct answer per spec would be NULL; or it might
yield an error complaining that it wasn't prepared for a NULL result.)
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.)
</para>
</note>
@ -488,7 +488,7 @@ table1.column1 OP table2.column2
<note>
<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
attempt to use the operator for a merge join.
</para>

4
doc/src/sgml/xtypes.sgml
View File

@ -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">
@ -241,7 +241,7 @@ CREATE TYPE complex (
the total length in bytes of the datum (including itself). The C
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
GETARG macros). Then,
<function>GETARG</function> macros). Then,
when running the <command>CREATE TYPE</command> command, specify the
internal length as <literal>variable</> and select the appropriate
storage option.