mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

This patch fixes a few missed GUC variables that were still upper case,

Browse Source 
makes a few more small improvements to runtime.sgml, and makes some SGML
conventions more consistent.

Neil Conway
This commit is contained in:
Bruce Momjian 2003-09-11 21:42:20 +00:00
parent 3d48045ae1
commit 2a5b6a7c9b
32 changed files with 336 additions and 295 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/src/sgml/docguide.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.44 2003/06/06 14:17:08 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.45 2003/09/11 21:42:19 momjian Exp $ -->
<appendix id="docguide">
<title>Documentation</title>
@ -497,8 +497,9 @@ CATALOG "docbook-dsssl--1.<replaceable>xx</>/catalog
<para>
Before you can build the documentation you need to run the
<filename>configure</filename> script as you would when building
the PostgreSQL programs themselves. Check the output near the end
of the run, it should look something like this:
the <productname>PostgreSQL</productname> programs themselves.
Check the output near the end of the run, it should look something
like this:
<screen>
<computeroutput>
checking for onsgmls... onsgmls
@ -640,7 +641,7 @@ gmake man.tar.gz
<title>Print Output via <acronym>RTF</acronym></title>
<para>
You can also create a printable version of the PostgreSQL
You can also create a printable version of the <productname>PostgreSQL</productname>
documentation by converting it to <acronym>RTF</acronym> and
applying minor formatting corrections using an office suite.
Depending on the capabilities of the particular office suite, you
@ -651,7 +652,7 @@ gmake man.tar.gz
<note>
<para>
It appears that current versions of the PostgreSQL documentation
It appears that current versions of the <productname>PostgreSQL</productname> documentation
trigger some bug in or exceed the size limit of OpenJade. If the
build process of the <acronym>RTF</acronym> version hangs for a
long time and the output file still has size 0, then you may have

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.50 2003/09/09 10:54:44 meskes Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.51 2003/09/11 21:42:19 momjian Exp $
-->
<chapter id="ecpg">
@ -1153,10 +1153,11 @@ struct
condition. A successful state is indicated by the code
<literal>00000</literal>. Further information about the codes can
be found XXX. The <literal>SQLSTATE</literal> codes are for the
most part defined in the SQL standard. The PostgreSQL server
natively supports <literal>SQLSTATE</literal> error codes;
therefore a high degree of consistency can be achieved by using
this error code scheme throughout all applications.
most part defined in the SQL standard. The
<productname>PostgreSQL</productname> server natively supports
<literal>SQLSTATE</literal> error codes; therefore a high degree
of consistency can be achieved by using this error code scheme
throughout all applications.
</para>
<para>
@ -1168,11 +1169,11 @@ struct
affected zero rows, and no specific negative values. Therefore,
this scheme can only achieve poor portability and does not have a
hierarchical code assignment. Historically, the embedded SQL
processor for PostgreSQL has assigned some specific
<literal>SQLCODE</literal> values for its use, which are listed
below with their numeric value and their symbolic name. Remember
that these are not portable to other SQL implementations. To
simplify the porting of applications to the
processor for <productname>PostgreSQL</productname> has assigned
some specific <literal>SQLCODE</literal> values for its use, which
are listed below with their numeric value and their symbolic name.
Remember that these are not portable to other SQL implementations.
To simplify the porting of applications to the
<literal>SQLSTATE</literal> scheme, the corresponding
<literal>SQLSTATE</literal> is also listed. There is, however, no
one-to-one or one-to-many mapping between the two schemes (indeed
@ -1291,9 +1292,10 @@ struct
<term>-208 (<symbol>ECPG_EMPTY</symbol>)</term>
<listitem>
<para>
The statement sent to the PostgreSQL server was empty. (This
cannot normally happen in an embedded SQL program, so it may
point to an internal error.) (SQLSTATE YE002)
The statement sent to the <productname>PostgreSQL</productname>
server was empty. (This cannot normally happen in an embedded
SQL program, so it may point to an internal error.) (SQLSTATE
YE002)
</para>
</listitem>
</varlistentry>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.24 2003/08/31 17:32:18 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.25 2003/09/11 21:42:19 momjian Exp $
-->
<chapter id="extend">
@ -69,14 +69,16 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.24 2003/08/31 17:32:18 pete
</para>
<para>
The PostgreSQL server can moreover incorporate user-written code into
itself through dynamic loading. That is, the user can
specify an object code file (e.g., a shared library) that implements a new type or function,
and <productname>PostgreSQL</productname> will load it as required. Code written
in <acronym>SQL</acronym> is even more trivial to add to the server.
This ability to modify its operation <quote>on the fly</quote> makes
<productname>PostgreSQL</productname> uniquely suited for rapid prototyping of new
applications and storage structures.
The <productname>PostgreSQL</productname> server can moreover
incorporate user-written code into itself through dynamic loading.
That is, the user can specify an object code file (e.g., a shared
library) that implements a new type or function, and
<productname>PostgreSQL</productname> will load it as required.
Code written in <acronym>SQL</acronym> is even more trivial to add
to the server. This ability to modify its operation <quote>on the
fly</quote> makes <productname>PostgreSQL</productname> uniquely
suited for rapid prototyping of new applications and storage
structures.
</para>
</sect1>

13
doc/src/sgml/features.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.18 2003/03/13 01:30:28 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.19 2003/09/11 21:42:19 momjian Exp $
-->
<appendix id="features">
@ -63,11 +63,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.18 2003/03/13 01:30:28 pe
In the following two sections, we provide a list of those features
that <productname>PostgreSQL</productname> supports, followed by a
list of the features defined in SQL99 which are not yet supported in
PostgreSQL. Both of these lists are approximate: There may be minor
details that are nonconforming for a feature that is listed as
supported, and large parts of an unsupported feature may in fact be
implemented. The main body of the documentation always contains the
most accurate information about what does and does not work.
<productname>PostgreSQL</productname>. Both of these lists are
approximate: There may be minor details that are nonconforming for a
feature that is listed as supported, and large parts of an
unsupported feature may in fact be implemented. The main body of
the documentation always contains the most accurate information
about what does and does not work.
</para>
<note>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.21 2003/09/08 23:02:28 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.22 2003/09/11 21:42:19 momjian Exp $
-->
<sect1 id="history">
@ -206,8 +206,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.21 2003/09/08 23:02:28 pet
</para>
<para>
Details about what has happened in PostgreSQL since then can be
found in <xref linkend="release">.
Details about what has happened in <productname>PostgreSQL</> since
then can be found in <xref linkend="release">.
</para>
</sect2>
</sect1>

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

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.43 2003/08/31 17:32:19 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.44 2003/09/11 21:42:19 momjian Exp $ -->
<chapter id="indexes">
<title id="indexes-title">Indexes</title>
@ -194,11 +194,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</synopsis>
<note>
<para>
Testing has shown PostgreSQL's hash indexes to be similar or slower
than B-tree indexes, and the index size and build time for hash
indexes is much worse. Hash indexes also suffer poor performance
under high concurrency. For these reasons, hash index use is
presently discouraged.
Testing has shown <productname>PostgreSQL</productname>'s hash
indexes to be similar or slower than B-tree indexes, and the
index size and build time for hash indexes is much worse. Hash
indexes also suffer poor performance under high concurrency. For
these reasons, hash index use is presently discouraged.
</para>
</note>
</para>

152
doc/src/sgml/information_schema.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/information_schema.sgml,v 1.6 2003/06/29 15:14:41 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/information_schema.sgml,v 1.7 2003/09/11 21:42:19 momjian Exp $ -->
<chapter id="information-schema">
<title>The Information Schema</title>
@ -12,11 +12,13 @@
information about the objects defined in the current database. The
information schema is defined in the SQL standard and can therefore
be expected to be portable and remain stable --- unlike the system
catalogs, which are specific to PostgreSQL and are modelled after
catalogs, which are specific to
<productname>PostgreSQL</productname> and are modelled after
implementation concerns. The information schema views do not,
however, contain information about PostgreSQL-specific features; to
inquire about those you need to query the system catalogs or other
PostgreSQL-specific views.
however, contain information about
<productname>PostgreSQL</productname>-specific features; to inquire
about those you need to query the system catalogs or other
<productname>PostgreSQL</productname>-specific views.
</para>
<sect1 id="infoschema-schema">
@ -319,12 +321,13 @@
</para>
<para>
In PostgreSQL, you can only grant privileges on entire tables, not
individual columns. Therefore, this view contains the same
information as <literal>table_privileges</literal>, just
represented through one row for each column in each appropriate
table, but it only convers privilege types where column granularity
is possible: <literal>SELECT</literal>, <literal>INSERT</literal>,
In <productname>PostgreSQL</productname>, you can only grant
privileges on entire tables, not individual columns. Therefore,
this view contains the same information as
<literal>table_privileges</literal>, just represented through one
row for each column in each appropriate table, but it only convers
privilege types where column granularity is possible:
<literal>SELECT</literal>, <literal>INSERT</literal>,
<literal>UPDATE</literal>, <literal>REFERENCES</literal>. If you
want to make your applications fit for possible future
developements, it is generally the right choice to use this view
@ -404,8 +407,8 @@
Note that the column <literal>grantee</literal> makes no
distinction between users and groups. If you have users and groups
with the same name, there is unfortunately no way to distinguish
them. A future version of PostgreSQL will possibly prohibit having
users and groups with the same name.
them. A future version of <productname>PostgreSQL</productname>
will possibly prohibit having users and groups with the same name.
</para>
</sect1>
@ -415,9 +418,9 @@
<para>
The view <literal>column_udt_usage</literal> identifies all columns
that use data types owned by the current user. Note that in
PostgreSQL, built-in data types behave like user-defined types, so
they are included here as well. See also <xref
linkend="infoschema-columns"> for details.
<productname>PostgreSQL</productname>, built-in data types behave
like user-defined types, so they are included here as well. See
also <xref linkend="infoschema-columns"> for details.
</para>
<table>
@ -595,7 +598,7 @@
<entry>
If <literal>data_type</literal> identifies a character type,
the maximum possible length in octets (bytes) of a datum (this
should not be of concern to PostgreSQL users); null for all
should not be of concern to <productname>PostgreSQL</productname> users); null for all
other data types.
</entry>
</row>
@ -800,24 +803,26 @@
<para>
Since data types can be defined in a variety of ways in SQL, and
PostgreSQL contains additional ways to define data types, their
representation in the information schema can be somewhat difficult.
The column <literal>data_type</literal> is supposed to identify the
underlying built-in type of the column. In PostgreSQL, this means
that the type is defined in the system catalog schema
<productname>PostgreSQL</productname> contains additional ways to
define data types, their representation in the information schema
can be somewhat difficult. The column <literal>data_type</literal>
is supposed to identify the underlying built-in type of the column.
In <productname>PostgreSQL</productname>, this means that the type
is defined in the system catalog schema
<literal>pg_catalog</literal>. This column may be useful if the
application can handle the well-known built-in types specially (for
example, format the numeric types differently or use the data in
the precision columns). The columns <literal>udt_name</literal>,
<literal>udt_schema</literal>, and <literal>udt_catalog</literal>
always identify the underlying data type of the column, even if the
column is based on a domain. (Since PostgreSQL treats built-in
types like user-defined types, built-in types appear here as well.
This is an extension of the SQL standard.) These columns should be
used if an application wants to process data differently according
to the type, because in that case it wouldn't matter if the column
is really based on a domain. If the column is based on a domain,
the identity of the domain is stored in the columns
column is based on a domain. (Since
<productname>PostgreSQL</productname> treats built-in types like
user-defined types, built-in types appear here as well. This is an
extension of the SQL standard.) These columns should be used if an
application wants to process data differently according to the
type, because in that case it wouldn't matter if the column is
really based on a domain. If the column is based on a domain, the
identity of the domain is stored in the columns
<literal>domain_name</literal>, <literal>domain_schema</literal>,
and <literal>domain_catalog</literal>. If you want to pair up
columns with their associated data types and treat domains as
@ -1141,8 +1146,8 @@
<para>
The view <literal>domain_udt_usage</literal> identifies all columns
that use data types owned by the current user. Note that in
PostgreSQL, built-in data types behave like user-defined types, so
they are included here as well.
<productname>PostgreSQL</productname>, built-in data types behave
like user-defined types, so they are included here as well.
</para>
<table>
@ -1266,7 +1271,8 @@
<entry>
If the domain has a character type, the maximum possible length
in octets (bytes) of a datum (this should not be of concern to
PostgreSQL users); null for all other data types.
<productname>PostgreSQL</productname> users); null for all
other data types.
</entry>
</row>
@ -2416,11 +2422,11 @@ ORDER BY c.ordinal_position;
The view <literal>role_usage_grants</literal> is meant to identify
<literal>USAGE</literal> privileges granted on various kinds of
objects to a group that the current user is a member of. In
PostgreSQL, this currently only applies to domains, and since
domains do not have real privileges in PostgreSQL, this view is
empty. Futher information can be found under
<literal>usage_privileges</literal>. In the future, this view may
contain more useful information.
<productname>PostgreSQL</productname>, this currently only applies
to domains, and since domains do not have real privileges in
<productname>PostgreSQL</productname>, this view is empty. Futher
information can be found under <literal>usage_privileges</literal>.
In the future, this view may contain more useful information.
</para>
<table>
@ -2582,8 +2588,8 @@ ORDER BY c.ordinal_position;
Note that the column <literal>grantee</literal> makes no
distinction between users and groups. If you have users and groups
with the same name, there is unfortunately no way to distinguish
them. A future version of PostgreSQL will possibly prohibit having
users and groups with the same name.
them. A future version of <productname>PostgreSQL</productname>
will possibly prohibit having users and groups with the same name.
</para>
</sect1>
@ -2874,8 +2880,9 @@ ORDER BY c.ordinal_position;
not the owner of the function). (According to the SQL
standard, this column is only applicable if
<literal>routine_body</literal> is <literal>SQL</literal>, but
in PostgreSQL it will contain whatever source text was
specified when the function was created.)
in <productname>PostgreSQL</productname> it will contain
whatever source text was specified when the function was
created.)
</entry>
</row>
@ -3082,9 +3089,9 @@ ORDER BY c.ordinal_position;
<para>
The table <literal>sql_features</literal> contains information
about which formal features defined in the SQL standard are
supported by PostgreSQL. This is the same information that is
presented in <xref linkend="features">. There you can also find
some additional background information.
supported by <productname>PostgreSQL</productname>. This is the
same information that is presented in <xref linkend="features">.
There you can also find some additional background information.
</para>
<table>
@ -3226,9 +3233,10 @@ ORDER BY c.ordinal_position;
<para>
The table <literal>sql_languages</literal> contains one row for
each SQL language binding that is supported by PostgreSQL.
PostgreSQL supports direct SQL and embedded SQL in C; that is all
you will learn from this table.
each SQL language binding that is supported by
<productname>PostgreSQL</productname>.
<productname>PostgreSQL</productname> supports direct SQL and
embedded SQL in C; that is all you will learn from this table.
</para>
<table>
@ -3313,8 +3321,8 @@ ORDER BY c.ordinal_position;
<para>
The table <literal>sql_packages</literal> contains information
about which features packages defined in the SQL standard are
supported by PostgreSQL. Refer to <xref linkend="features"> for
background information on feature packages.
supported by <productname>PostgreSQL</productname>. Refer to <xref
linkend="features"> for background information on feature packages.
</para>
<table>
@ -3375,12 +3383,13 @@ ORDER BY c.ordinal_position;
<para>
The table <literal>sql_sizing</literal> contains information about
various size limits and maximum values in PostgreSQL. This
information is primarily intended for use in the context of the
ODBC interface; users of other interfaces will probably find this
information to be of little use. For this reason, the individual
sizing items are not described here; you will find them in the
description of the ODBC interface.
various size limits and maximum values in
<productname>PostgreSQL</productname>. This information is
primarily intended for use in the context of the ODBC interface;
users of other interfaces will probably find this information to be
of little use. For this reason, the individual sizing items are
not described here; you will find them in the description of the
ODBC interface.
</para>
<table>
@ -3657,8 +3666,8 @@ ORDER BY c.ordinal_position;
Note that the column <literal>grantee</literal> makes no
distinction between users and groups. If you have users and groups
with the same name, there is unfortunately no way to distinguish
them. A future version of PostgreSQL will possibly prohibit having
users and groups with the same name.
them. A future version of <productname>PostgreSQL</productname>
will possibly prohibit having users and groups with the same name.
</para>
</sect1>
@ -3875,21 +3884,23 @@ ORDER BY c.ordinal_position;
</table>
<para>
Triggers in PostgreSQL have two incompatibilities with the SQL
standard that affect the representation in the information schema.
First, trigger names are local to the table in PostgreSQL, rather
Triggers in <productname>PostgreSQL</productname> have two
incompatibilities with the SQL standard that affect the
representation in the information schema. First, trigger names are
local to the table in <productname>PostgreSQL</productname>, rather
than independent schema objects. Therefore there may be duplicate
trigger names defined in one schema, as long as they belong to
different tables. (<literal>trigger_catalog</literal> and
<literal>trigger_schema</literal> are really the values pertaining
to the table that the trigger is defined on.) Second, triggers can
be defined to fire on multiple events in PostgreSQL (e.g.,
<literal>ON INSERT OR UPDATE</literal>), whereas the SQL standard
only allows one. If a trigger is defined to fire on multiple
events, it is represented as multiple rows in the information
schema, one for each type of event. As a consequence of these two
issues, the primary key of the view <literal>triggers</literal> is
really <literal>(trigger_catalog, trigger_schema, trigger_name,
be defined to fire on multiple events in
<productname>PostgreSQL</productname> (e.g., <literal>ON INSERT OR
UPDATE</literal>), whereas the SQL standard only allows one. If a
trigger is defined to fire on multiple events, it is represented as
multiple rows in the information schema, one for each type of
event. As a consequence of these two issues, the primary key of
the view <literal>triggers</literal> is really
<literal>(trigger_catalog, trigger_schema, trigger_name,
event_object_name, event_manipulation)</literal> instead of
<literal>(trigger_catalog, trigger_schema, trigger_name)</literal>,
which is what the SQL standard specifies. Nonetheless, if you
@ -3905,9 +3916,10 @@ ORDER BY c.ordinal_position;
<para>
The view <literal>usage_privileges</literal> is meant to identify
<literal>USAGE</literal> privileges granted on various kinds of
objects to the current user or by the current user. In PostgreSQL,
this currently only applies to domains, and since domains do not
have real privileges in PostgreSQL, this view shows implicit
objects to the current user or by the current user. In
<productname>PostgreSQL</productname>, this currently only applies
to domains, and since domains do not have real privileges in
<productname>PostgreSQL</productname>, this view shows implicit
<literal>USAGE</literal> privileges granted to
<literal>PUBLIC</literal> for all domains. In the future, this
view may contain more useful information.

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

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.140 2003/09/01 23:01:49 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.141 2003/09/11 21:42:20 momjian Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
@ -406,13 +406,14 @@ JAVACMD=$JAVA_HOME/bin/java
To make the backup, you can use the <command>pg_dumpall</command>
command from the version you are currently running. For best
results, however, try to use the <command>pg_dumpall</command>
command from PostgreSQL &version;, since this version contains
bug fixes and improvements over older versions. While this
advice might seem idiosyncratic since you haven't installed the
new version yet, it is advisable to follow it if you plan to
install the new version in parallel with the old version. In
that case you can complete the installation normally and transfer
the data later. This will also decrease the downtime.
command from <productname>PostgreSQL</productname> &version;,
since this version contains bug fixes and improvements over older
versions. While this advice might seem idiosyncratic since you
haven't installed the new version yet, it is advisable to follow
it if you plan to install the new version in parallel with the
old version. In that case you can complete the installation
normally and transfer the data later. This will also decrease
the downtime.
</para>
</step>

43
doc/src/sgml/intro.sgml
View File

@ -1,23 +1,26 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.21 2003/09/08 23:02:28 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.22 2003/09/11 21:42:20 momjian Exp $
-->
<preface id="preface">
<title>Preface</title>
<para>
This book is the official documentation of PostgreSQL. It is being
written by the PostgreSQL developers and other volunteers in
parallel to the development of the PostgreSQL software. It
describes all the functionality that the current version of
PostgreSQL officially supports.
This book is the official documentation of
<productname>PostgreSQL</productname>. It is being written by the
<productname>PostgreSQL</productname> developers and other
volunteers in parallel to the development of the
<productname>PostgreSQL</productname> software. It describes all
the functionality that the current version of
<productname>PostgreSQL</productname> officially supports.
</para>
<para>
To make the large amount of information about PostgreSQL manageable,
this book has been organized in several parts. Each part is
targeted at a different class of users, or at users in different
stages of their PostgreSQL experience:
To make the large amount of information about
<productname>PostgreSQL</productname> manageable, this book has been
organized in several parts. Each part is targeted at a different
class of users, or at users in different stages of their
<productname>PostgreSQL</productname> experience:
<itemizedlist>
<listitem>
@ -38,16 +41,17 @@ $Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.21 2003/09/08 23:02:28 peter
<listitem>
<para>
<xref linkend="admin"> describes the installation and
administration of the server. Everyone that runs a PostgreSQL
server, be it for private use or for others, should read this
part.
administration of the server. Everyone that runs a
<productname>PostgreSQL</productname> server, be it for private
use or for others, should read this part.
</para>
</listitem>
<listitem>
<para>
<xref linkend="client-interfaces"> describes the programming
interfaces for PostgreSQL client programs.
interfaces for <productname>PostgreSQL</productname> client
programs.
</para>
</listitem>
@ -111,8 +115,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.21 2003/09/08 23:02:28 peter
</listitem>
</itemizedlist>
Also, PostgreSQL can be extended by the user in many ways, for
example by adding new
Also, <productname>PostgreSQL</productname> can be extended by the
user in many ways, for example by adding new
<itemizedlist spacing="compact">
<listitem>
@ -137,9 +141,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/intro.sgml,v 1.21 2003/09/08 23:02:28 peter
</para>
<para>
And because of the liberal license, PostgreSQL can be used,
modified, and distributed by everyone free of charge for any
purpose, be it private, commercial, or academic.
And because of the liberal license,
<productname>PostgreSQL</productname> can be used, modified, and
distributed by everyone free of charge for any purpose, be it
private, commercial, or academic.
</para>
</sect1>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.135 2003/09/03 22:05:01 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.136 2003/09/11 21:42:20 momjian Exp $
-->
<chapter id="libpq">
@ -2049,11 +2049,13 @@ unsigned char *PQescapeBytea(const unsigned char *from,
<parameter>from</parameter> parameter binary string in memory
allocated with <function>malloc()</>. This memory must be freed
using <function>PQfreemem()</> when the result is no longer needed.
The return string has all special characters replaced
so that they can be properly processed by the PostgreSQL string literal
parser, and the <type>bytea</type> input function. A terminating zero
byte is also added. The single quotes that must surround
PostgreSQL string literals are not part of the result string.
The return string has all special characters replaced so that they
can be properly processed by the
<productname>PostgreSQL</productname> string literal parser, and
the <type>bytea</type> input function. A terminating zero byte is
also added. The single quotes that must surround
<productname>PostgreSQL</productname> string literals are not part
of the result string.
</para>
</listitem>
</varlistentry>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.24 2003/09/11 18:30:38 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.25 2003/09/11 21:42:20 momjian Exp $
-->
<chapter id="plpgsql">
@ -2056,9 +2056,10 @@ RAISE <replaceable class="parameter">level</replaceable> '<replaceable class="pa
(raise an error and abort the current transaction). Whether
messages of a particular priority are reported to the client,
written to the server log, or both is controlled by the
<option>log_min_messages</option> and
<option>client_min_messages</option> configuration variables. See
<xref linkend="runtime-config"> for more information.
<varname>log_min_messages</varname> and
<varname>client_min_messages</varname> configuration
variables. See <xref linkend="runtime-config"> for more
information.
</para>
<para>
@ -2448,7 +2449,8 @@ show errors;
<para>
The <literal>RETURN</literal> key word in the function
prototype (not the function body) becomes
<literal>RETURNS</literal> in PostgreSQL.
<literal>RETURNS</literal> in
<productname>PostgreSQL</productname>.
</para>
</listitem>
@ -2805,7 +2807,8 @@ END;
<para>
This section explains a few other things to watch for when porting
Oracle <application>PL/SQL</> functions to PostgreSQL.
Oracle <application>PL/SQL</> functions to
<productname>PostgreSQL</productname>.
</para>
<sect3>

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

@ -1,10 +1,10 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.43 2003/09/03 22:05:07 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.44 2003/09/11 21:42:20 momjian Exp $ -->
<chapter id="protocol">
<title>Frontend/Backend Protocol</title>
<para>
<application>PostgreSQL</application> uses a message-based protocol
<productname>PostgreSQL</productname> uses a message-based protocol
for communication between frontends and backends (clients and servers).
The protocol is supported over <acronym>TCP/IP</acronym> and also over
Unix-domain sockets. Port number 5432 has been registered with IANA as
@ -14,7 +14,7 @@
<para>
This document describes version 3.0 of the protocol, implemented in
<application>PostgreSQL</application> 7.4 and later. For descriptions
<productname>PostgreSQL</productname> 7.4 and later. For descriptions
of the earlier protocol versions, see previous releases of the
<productname>PostgreSQL</productname> documentation. A single server
can support multiple protocol versions. The initial
@ -165,7 +165,7 @@
<para>
Data of a particular datatype might be transmitted in any of several
different <firstterm>formats</>. As of <application>PostgreSQL</> 7.4
different <firstterm>formats</>. As of <productname>PostgreSQL</> 7.4
the only supported formats are <quote>text</> and <quote>binary</>,
but the protocol makes provision for future extensions. The desired
format for any value is specified by a <firstterm>format code</>.

8
doc/src/sgml/ref/copy.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.49 2003/09/09 18:28:52 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.50 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -201,7 +201,7 @@ COPY <replaceable class="parameter">table</replaceable> [ ( <replaceable class="
directly by the server, not by the client application. Therefore,
they must reside on or be accessible to the database server machine,
not the client. They must be accessible to and readable or writable
by the <application>PostgreSQL</application> user (the user ID the
by the <productname>PostgreSQL</productname> user (the user ID the
server runs as), not the client. <command>COPY</command> naming a
file is only allowed to database superusers, since it allows reading
or writing any file that the server has privileges to access.
@ -367,7 +367,7 @@ COPY <replaceable class="parameter">table</replaceable> [ ( <replaceable class="
<para>
The file format used for <command>COPY BINARY</command> changed in
<application>PostgreSQL</application> 7.4. The new format consists
<productname>PostgreSQL</productname> 7.4. The new format consists
of a file header, zero or more tuples containing the row data, and
a file trailer. Headers and data are now in network byte order.
</para>
@ -474,7 +474,7 @@ to be specified.
<para>
To determine the appropriate binary format for the actual tuple data you
should consult the <application>PostgreSQL</application> source, in
should consult the <productname>PostgreSQL</productname> source, in
particular the <function>*send</> and <function>*recv</> functions for
the data type (typically found in the <filename>src/backend/utils/adt</filename>
directory). The <application>contrib/binarycopy</application> module

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.51 2003/09/10 20:13:45 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.52 2003/09/11 21:42:20 momjian Exp $
-->
<refentry id="SQL-CREATEFUNCTION">
@ -382,7 +382,7 @@ CREATE FUNCTION add(integer, integer) RETURNS integer
<para>
A <command>CREATE FUNCTION</command> command is defined in SQL99.
The <application>PostgreSQL</application> version is similar but
The <productname>PostgreSQL</productname> version is similar but
not fully compatible. The attributes are not portable, neither are the
different available languages.
</para>

6
doc/src/sgml/ref/create_index.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.41 2003/09/09 18:28:52 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.42 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -53,7 +53,7 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
</para>
<para>
<application>PostgreSQL</application> provides the index methods
<productname>PostgreSQL</productname> provides the index methods
B-tree, R-tree, hash, and GiST. The B-tree index method is an
implementation of Lehman-Yao high-concurrency B-trees. The R-tree
index method implements standard R-trees using Guttman's quadratic
@ -198,7 +198,7 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
Currently, only the B-tree and GiST index methods support
multicolumn indexes. Up to 32 fields may be specified by default.
(This limit can be altered when building
<application>PostgreSQL</application>.) Only B-tree currently
<productname>PostgreSQL</productname>.) Only B-tree currently
supports unique indexes.
</para>

8
doc/src/sgml/ref/declare.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/declare.sgml,v 1.26 2003/08/31 17:32:22 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/declare.sgml,v 1.27 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -105,9 +105,9 @@ DECLARE <replaceable class="parameter">cursorname</replaceable> [ BINARY ] [ INS
<para>
Indicates that data retrieved from the cursor should be
unaffected by updates to the tables underlying the cursor while
the cursor exists. In PostgreSQL, all cursors are insensitive;
this key word currently has no effect and is present for
compatibility with the SQL standard.
the cursor exists. In <productname>PostgreSQL</productname>,
all cursors are insensitive; this key word currently has no
effect and is present for compatibility with the SQL standard.
</para>
</listitem>
</varlistentry>

8
doc/src/sgml/ref/end.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/end.sgml,v 1.10 2003/08/31 17:32:23 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/end.sgml,v 1.11 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -30,9 +30,9 @@ END [ WORK | TRANSACTION ]
<para>
<command>END</command> commits the current transaction. All changes
made by the transaction become visible to others and are guaranteed
to be durable if a crash occurs. It is a PostgreSQL extension that
is equivalent to <xref linkend="sql-commit"
endterm="sql-commit-title">.
to be durable if a crash occurs. It is a
<productname>PostgreSQL</productname> extension that is equivalent
to <xref linkend="sql-commit" endterm="sql-commit-title">.
</para>
</refsect1>

6
doc/src/sgml/ref/grant.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.34 2003/08/31 17:32:23 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.35 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -375,8 +375,8 @@ GRANT <replaceable class="PARAMETER">privileges</replaceable>
<para>
The <literal>RULE</literal> privilege, and privileges on
databases, schemas, languages, and sequences are PostgreSQL
extensions.
databases, schemas, languages, and sequences are
<productname>PostgreSQL</productname> extensions.
</para>
</refsect1>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/load.sgml,v 1.18 2003/08/31 17:32:23 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/load.sgml,v 1.19 2003/09/11 21:42:20 momjian Exp $
-->
<refentry id="SQL-LOAD">
@ -50,7 +50,7 @@ LOAD '<replaceable class="PARAMETER">filename</replaceable>'
<title>Compatibility</title>
<para>
<command>LOAD</command> is a <application>PostgreSQL</application>
<command>LOAD</command> is a <productname>PostgreSQL</productname>
extension.
</para>
</refsect1>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.37 2003/09/09 18:28:53 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.38 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -201,7 +201,7 @@ COMMIT WORK;
<para>
There is no <command>LOCK TABLE</command> in the SQL standard,
which instead uses <command>SET TRANSACTION</command> to specify
concurrency levels on transactions. PostgreSQL supports that too;
concurrency levels on transactions. <productname>PostgreSQL</productname> supports that too;
see <xref linkend="SQL-SET-TRANSACTION"
endterm="SQL-SET-TRANSACTION-TITLE"> for details.
</para>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.63 2003/08/31 17:32:23 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.64 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -705,7 +705,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
The <application>pg_dump</application> utility first appeared in
<application>Postgres95</application> release 0.02. The
non-plain-text output formats were introduced in
<application>PostgreSQL</application> release 7.1.
<productname>PostgreSQL</productname> release 7.1.
</para>
</refsect1>

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

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.41 2003/08/31 17:32:24 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.42 2003/09/11 21:42:20 momjian Exp $ -->
<refentry id="APP-PGRESTORE">
<refmeta>
@ -659,7 +659,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
<para>
The <application>pg_restore</application> utility first appeared in
PostgreSQL 7.1.
<productname>PostgreSQL</productname> 7.1.
</para>
</refsect1>

13
doc/src/sgml/ref/reindex.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v 1.19 2003/09/09 18:28:53 tgl Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v 1.20 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -46,11 +46,12 @@ REINDEX { DATABASE | TABLE | INDEX } <replaceable class="PARAMETER">name</replac
<listitem>
<para>
The index in question contains a lot of dead index pages that
are not being reclaimed. This can occur with B-tree indexes in PostgreSQL
under certain access patterns. <command>REINDEX</command>
provides a way to reduce the space consumption of the index by
writing a new version of the index without the dead pages. See
<xref linkend="routine-reindex"> for more information.
are not being reclaimed. This can occur with B-tree indexes in
<productname>PostgreSQL</productname> under certain access
patterns. <command>REINDEX</command> provides a way to reduce
the space consumption of the index by writing a new version of
the index without the dead pages. See <xref
linkend="routine-reindex"> for more information.
</para>
</listitem>
</itemizedlist>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.69 2003/08/31 17:32:24 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.70 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -798,10 +798,10 @@ FOR UPDATE [ OF <replaceable class="parameter">table_name</replaceable> [, ...]
<para>
<literal>FOR UPDATE</literal> may appear before
<literal>LIMIT</literal> for compatibility with PostgreSQL
versions before 7.3. It effectively executes after
<literal>LIMIT</literal>, however, and so that is the recommended
place to write it.
<literal>LIMIT</literal> for compatibility with
<productname>PostgreSQL</productname> versions before 7.3. It
effectively executes after <literal>LIMIT</literal>, however, and
so that is the recommended place to write it.
</para>
</refsect2>
</refsect1>
@ -1008,11 +1008,12 @@ SELECT d.* FROM distributors d;
SELECT distributors.* FROM distributors d, distributors distributors;
</programlisting>
that he will actually get. To help detect this sort of mistake,
PostgreSQL will warn if the implicit-<literal>FROM</literal>
feature is used in a <command>SELECT</command> statement that also
contains an explicit <literal>FROM</literal> clause. Also, it is
possible to disable the implicit-<literal>FROM</literal> feature
by setting the <varname>ADD_MISSING_FROM</> parameter to false.
<productname>PostgreSQL</productname> will warn if the
implicit-<literal>FROM</literal> feature is used in a
<command>SELECT</command> statement that also contains an explicit
<literal>FROM</literal> clause. Also, it is possible to disable
the implicit-<literal>FROM</literal> feature by setting the
<varname>ADD_MISSING_FROM</> parameter to false.
</para>
</refsect2>

7
doc/src/sgml/ref/set_constraints.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.7 2003/08/31 17:32:24 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.8 2003/09/11 21:42:20 momjian Exp $ -->
<refentry id="SQL-SET-CONSTRAINTS">
<refmeta>
<refentrytitle id="SQL-SET-CONSTRAINTS-title">SET CONSTRAINTS</refentrytitle>
@ -77,8 +77,9 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">constraint</replaceable>
<para>
This command complies with the behavior defined in the SQL
standard, except for the limitation that, in PostgreSQL, it only
applies to foreign-key constraints.
standard, except for the limitation that, in
<productname>PostgreSQL</productname>, it only applies to
foreign-key constraints.
</para>
</refsect1>
</refentry>

6
doc/src/sgml/ref/set_session_auth.sgml
View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.10 2003/08/31 17:32:24 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.11 2003/09/11 21:42:20 momjian Exp $ -->
<refentry id="SQL-SET-SESSION-AUTHORIZATION">
<refmeta>
<refentrytitle id="sql-set-session-authorization-title">SET SESSION AUTHORIZATION</refentrytitle>
@ -89,10 +89,10 @@ SELECT SESSION_USER, CURRENT_USER;
<para>
The SQL standard allows some other expressions to appear in place
of the literal <replaceable>username</replaceable> which are not
important in practice. <application>PostgreSQL</application>
important in practice. <productname>PostgreSQL</productname>
allows identifier syntax (<literal>"username"</literal>), which SQL
does not. SQL does not allow this command during a transaction;
<application>PostgreSQL</application> does not make this
<productname>PostgreSQL</productname> does not make this
restriction because there is no reason to. The privileges
necessary to execute this command are left implementation-defined
by the standard.

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

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_transaction.sgml,v 1.16 2003/09/09 18:28:53 tgl Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_transaction.sgml,v 1.17 2003/09/11 21:42:20 momjian Exp $ -->
<refentry id="SQL-SET-TRANSACTION">
<refmeta>
<refentrytitle id="SQL-SET-TRANSACTION-TITLE">SET TRANSACTION</refentrytitle>
@ -122,7 +122,7 @@ SET default_transaction_isolation = '<replaceable>value</replaceable>'
<para>
Both commands are defined in the <acronym>SQL</acronym> standard.
<literal>SERIALIZABLE</literal> is the default transaction
isolation level in the standard; in PostgreSQL the default is
isolation level in the standard; in <productname>PostgreSQL</productname> the default is
ordinarily <literal>READ COMMITTED</literal>, but you can change it as
described above. <productname>PostgreSQL</productname> does not
provide the isolation levels <literal>READ UNCOMMITTED</literal>

5
doc/src/sgml/ref/update.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.24 2003/08/31 17:32:24 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.25 2003/09/11 21:42:20 momjian Exp $
PostgreSQL documentation
-->
@ -164,7 +164,8 @@ UPDATE weather SET temp_lo = temp_lo+1, temp_hi = temp_lo+15, prcp = DEFAULT
<para>
This command conforms to the SQL standard. The
<literal>FROM</literal> clause is a PostgreSQL extension.
<literal>FROM</literal> clause is a
<productname>PostgreSQL</productname> extension.
</para>
</refsect1>
</refentry>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.206 2003/08/27 03:35:35 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.207 2003/09/11 21:42:20 momjian Exp $
-->
<appendix id="release">
@ -10,8 +10,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.206 2003/08/27 03:35:35 mo
<para>
Below is a subset of the changes that have gone into the
development branch of PostgreSQL since version 7.3. For a complete
list of changes, consult the CVS logs.
development branch of <productname>PostgreSQL</productname> since
version 7.3. For a complete list of changes, consult the CVS logs.
</para>
<!--

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

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.29 2003/08/31 17:32:19 petere Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.30 2003/09/11 21:42:20 momjian Exp $ -->
<Chapter Id="rules">
<Title>The Rule System</Title>
@ -8,16 +8,17 @@
</indexterm>
<Para>
This chapter discusses the rule system in PostgreSQL.
Production rule systems are conceptually simple, but
there are many subtle points involved in actually using
them.
This chapter discusses the rule system in
<productname>PostgreSQL</productname>. Production rule systems
are conceptually simple, but there are many subtle points
involved in actually using them.
</Para>
<Para>
Some other database systems define active database rules, which
are usually stored procedures and triggers. In PostgreSQL, these
can be implemented using functions and triggers as well.
are usually stored procedures and triggers. In
<productname>PostgreSQL</productname>, these can be implemented
using functions and triggers as well.
</Para>
<Para>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.206 2003/09/11 18:30:39 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.207 2003/09/11 21:42:20 momjian Exp $
-->
<Chapter Id="runtime">
@ -797,7 +797,7 @@ SET ENABLE_SEQSCAN TO OFF;
this much time, the server breaks the connection. This prevents
hung clients from occupying a connection indefinitely. This
option can only be set at server start or in the
<filename>postgresql.conf</filename> file.
<filename>postgresql.conf</filename> file. The default is 60.
</para>
</listitem>
</varlistentry>
@ -1028,9 +1028,9 @@ SET ENABLE_SEQSCAN TO OFF;
</para>
<para>
PostgreSQL procedural language libraries may be preloaded in
this way, typically by using the syntax
<literal>'$libdir/plXXX:plXXX_init'</literal> where
<productname>PostgreSQL</productname> procedural language
libraries may be preloaded in this way, typically by using the
syntax <literal>'$libdir/plXXX:plXXX_init'</literal> where
<literal>XXX</literal> is <literal>pgsql</>, <literal>perl</>,
<literal>tcl</>, or <literal>python</>.
</para>
@ -1228,11 +1228,11 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
These configuration parameters provide a crude method for
influencing the query plans chosen by the query optimizer. If
the default plan chosen by the optimizer is not optimal, a
temporary solution may be found by using one of these
configuration parameters to force the optimizer to choose a
better plan. Other ways to improve the quality of the plans
chosen by the optimizer include configuring the <xref
the default plan chosen by the optimizer for a particular query
is not optimal, a temporary solution may be found by using one
of these configuration parameters to force the optimizer to
choose a better plan. Other ways to improve the quality of the
plans chosen by the optimizer include configuring the <xref
linkend="runtime-config-query-constants"
endterm="runtime-config-query-constants-title">, running
<command>ANALYZE</command> more frequently, and increasing the
@ -1370,7 +1370,7 @@ SET ENABLE_SEQSCAN TO OFF;
disk cache (that is, the portion of the kernel's disk cache
that will be used for <productname>PostgreSQL</productname>
data files). This is measured in disk pages, which are
normally 8192 bytes each.
normally 8192 bytes each. The default is 1000.
</para>
</listitem>
</varlistentry>
@ -1382,8 +1382,9 @@ SET ENABLE_SEQSCAN TO OFF;
Sets the query planner's estimate of the cost of a
nonsequentially fetched disk page. This is measured as a
multiple of the cost of a sequential page fetch. A higher
value makes it more likely a sequential scan will be used,
a lower value makes it more likely an index scan will be used.
value makes it more likely a sequential scan will be used, a
lower value makes it more likely an index scan will be
used. The default is four.
</para>
</listitem>
</varlistentry>
@ -1394,7 +1395,7 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
Sets the query planner's estimate of the cost of processing
each tuple during a query. This is measured as a fraction of
the cost of a sequential page fetch.
the cost of a sequential page fetch. The default is 0.01.
</para>
</listitem>
</varlistentry>
@ -1405,7 +1406,8 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
Sets the query planner's estimate of the cost of processing
each index tuple during an index scan. This is measured as a
fraction of the cost of a sequential page fetch.
fraction of the cost of a sequential page fetch. The default
is 0.001.
</para>
</listitem>
</varlistentry>
@ -1416,7 +1418,7 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
Sets the planner's estimate of the cost of processing each
operator in a <literal>WHERE</> clause. This is measured as a fraction of
the cost of a sequential page fetch.
the cost of a sequential page fetch. The default is 0.0025.
</para>
</listitem>
</varlistentry>
@ -1502,7 +1504,7 @@ SET ENABLE_SEQSCAN TO OFF;
had a column-specific target set via <command>ALTER TABLE SET
STATISTICS</>. Larger values increase the time needed to do
<command>ANALYZE</>, but may improve the quality of the planner's
estimates. The default value is 10.
estimates. The default is 10.
</para>
</listitem>
</varlistentry>
@ -1650,8 +1652,8 @@ SET ENABLE_SEQSCAN TO OFF;
<listitem>
<para>
Controls the amount of detail written in the server log for each
message that is logged. Valid values are <literal>terse</>,
<literal>default</>, and <literal>verbose</>, each adding more
message that is logged. Valid values are <literal>TERSE</>,
<literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
fields to displayed messages.
</para>
</listitem>
@ -1813,14 +1815,15 @@ SET ENABLE_SEQSCAN TO OFF;
<term><varname>debug_pretty_print</varname> (<type>boolean</type>)</term>
<listitem>
<para>
These options enable various debugging output to be sent to the
client or server log. For each executed query, they print the resulting
parse tree, the query rewriter output, or the execution plan.
<option>DEBUG_PRETTY_PRINT</option> indents these displays to
produce a more readable but much longer output format.
<option>CLIENT_MIN_MESSAGES</option> or <option>LOG_MIN_MESSAGES</option>
must be <literal>DEBUG1</literal> or lower to send output to the client
or server logs.
These options enable various debugging output to be sent to
the client or server log. For each executed query, they print
the resulting parse tree, the query rewriter output, or the
execution plan. <varname>debug_pretty_print</varname> indents
these displays to produce a more readable but much longer
output format. <varname>client_min_messages</varname> or
<varname>log_min_messages</varname> must be
<literal>DEBUG1</literal> or lower to send output to the
client or server logs. These options are off by default.
</para>
</listitem>
</varlistentry>
@ -1845,7 +1848,7 @@ SET ENABLE_SEQSCAN TO OFF;
Causes the duration of every completed statement to be logged.
To use this option, enable <varname>log_statement</> and
<varname>log_pid</> so you can link the statement to the
duration using the process ID.
duration using the process ID. The default is off.
Only superusers can turn off this option if it is enabled by
the administrator.
</para>
@ -1869,7 +1872,7 @@ SET ENABLE_SEQSCAN TO OFF;
<term><varname>log_statement</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Causes each SQL statement to be logged.
Causes each SQL statement to be logged. The default is off.
Only superusers can turn off this option if it is enabled by
the administrator.
</para>
@ -1932,9 +1935,9 @@ SET ENABLE_SEQSCAN TO OFF;
<para>
For each query, write performance statistics of the respective
module to the server log. This is a crude profiling
instrument.
Only superusers can turn off this option if it is enabled by
the administrator.
instrument. All of these options are disabled by default.
Only superusers can turn off any of these options if they have
been enabled by the administrator.
</para>
</listitem>
</varlistentry>
@ -2127,7 +2130,8 @@ SET ENABLE_SEQSCAN TO OFF;
<listitem>
<para>
Aborts any statement that takes over the specified number of
milliseconds. A value of zero turns off the timer.
milliseconds. A value of zero turns off the timer, which is
the default value.
</para>
</listitem>
</varlistentry>
@ -2300,8 +2304,9 @@ SET ENABLE_SEQSCAN TO OFF;
<term><varname>explain_pretty_print</varname> (<type>boolean</type>)</term>
<listitem>
<para>
Determines whether <command>EXPLAIN VERBOSE</> uses the indented
or non-indented format for displaying detailed query-tree dumps.
Determines whether <command>EXPLAIN VERBOSE</> uses the
indented or non-indented format for displaying detailed
query-tree dumps. The default is on.
</para>
</listitem>
</varlistentry>
@ -2357,9 +2362,9 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<listitem>
<para>
Sets the maximum expression nesting depth of the parser. The
default value is high enough for any normal query, but you can
raise it if needed. (But if you raise it too high, you run
the risk of server crashes due to stack overflow.)
default value of 10000 is high enough for any normal query,
but you can raise it if needed. (But if you raise it too high,
you run the risk of server crashes due to stack overflow.)
</para>
</listitem>
</varlistentry>
@ -2409,7 +2414,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<listitem>
<para>
The shared lock table is sized on the assumption that at most
<varname>max_locks_per_transaction</> *
<varname>max_locks_per_transaction</varname> *
<varname>max_connections</varname> distinct objects will need to
be locked at any one time. The default, 64, has historically
proven sufficient, but you might need to raise this value if you
@ -2453,7 +2458,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<para>
The regular expression <quote>flavor</> can be set to
<literal>advanced</>, <literal>extended</>, or <literal>basic</>.
The usual default is <literal>advanced</>. The <literal>extended</>
The default is <literal>advanced</>. The <literal>extended</>
setting may be useful for exact backwards compatibility with
pre-7.4 releases of <productname>PostgreSQL</>.
</para>
@ -2533,13 +2538,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<title>Developer Options</title>
<para>
The following options are intended for work on the PostgreSQL source,
and in some cases to assist with recovery of
severely damaged databases. There should be no reason to use them in
a production database setup. As such, they have been excluded from the
sample <filename>postgresql.conf</> file.
Note that many of these options require special
source compilation flags to work at all.
The following options are intended for work on the
<productname>PostgreSQL</productname> source, and in some cases
to assist with recovery of severely damaged databases. There
should be no reason to use them in a production database setup.
As such, they have been excluded from the sample
<filename>postgresql.conf</> file. Note that many of these
options require special source compilation flags to work at all.
</para>
<variablelist>
@ -2580,9 +2585,9 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
<para>
Generates a great amount of debugging output for the
<command>LISTEN</command> and <command>NOTIFY</command>
commands.
<option>CLIENT_MIN_MESSAGES</option> or <option>LOG_MIN_MESSAGES</option>
must be <literal>DEBUG1</literal> or lower to send this output to the
commands. <varname>client_min_messages</varname> or
<varname>log_min_messages</varname> must be
<literal>DEBUG1</literal> or lower to send this output to the
client or server log, respectively.
</para>
</listitem>

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

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.73 2003/08/31 17:32:20 petere Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.74 2003/09/11 21:42:20 momjian Exp $
-->
<sect1 id="xfunc">
@ -814,15 +814,15 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
<para>
To know how to write C-language functions, you need to know how
PostgreSQL internally represents base data types and how they can
be passed to and from functions.
Internally, <productname>PostgreSQL</productname> regards a
base type as a <quote>blob of memory</quote>. The user-defined
functions that you define over a type in turn define the
way that <productname>PostgreSQL</productname> can operate
on it. That is, <productname>PostgreSQL</productname> will
only store and retrieve the data from disk and use your
user-defined functions to input, process, and output the data.
<productname>PostgreSQL</productname> internally represents base
data types and how they can be passed to and from functions.
Internally, <productname>PostgreSQL</productname> regards a base
type as a <quote>blob of memory</quote>. The user-defined
functions that you define over a type in turn define the way that
<productname>PostgreSQL</productname> can operate on it. That
is, <productname>PostgreSQL</productname> will only store and
retrieve the data from disk and use your user-defined functions
to input, process, and output the data.
</para>
<para>
@ -1249,13 +1249,14 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
<para>
Here, <replaceable>DIRECTORY</replaceable> stands for the
directory of the shared library file (for instance the PostgreSQL
tutorial directory, which contains the code for the examples used
in this section). (Better style would be to use just
<literal>'funcs'</> in the <literal>AS</> clause, after having
added <replaceable>DIRECTORY</replaceable> to the search path.
In any case, we may omit the system-specific extension for a
shared library, commonly <literal>.so</literal> or
directory of the shared library file (for instance the
<productname>PostgreSQL</productname> tutorial directory, which
contains the code for the examples used in this section).
(Better style would be to use just <literal>'funcs'</> in the
<literal>AS</> clause, after having added
<replaceable>DIRECTORY</replaceable> to the search path. In any
case, we may omit the system-specific extension for a shared
library, commonly <literal>.so</literal> or
<literal>.sl</literal>.)
</para>
@ -1483,15 +1484,16 @@ concat_text(PG_FUNCTION_ARGS)
<para>
Before we turn to the more advanced topics, we should discuss
some coding rules for PostgreSQL C-language functions. While it
may be possible to load functions written in languages other than
C into <productname>PostgreSQL</productname>, this is usually
difficult (when it is possible at all) because other languages,
such as C++, FORTRAN, or Pascal often do not follow the same
calling convention as C. That is, other languages do not pass
argument and return values between functions in the same way.
For this reason, we will assume that your C-language functions
are actually written in C.
some coding rules for <productname>PostgreSQL</productname>
C-language functions. While it may be possible to load functions
written in languages other than C into
<productname>PostgreSQL</productname>, this is usually difficult
(when it is possible at all) because other languages, such as
C++, FORTRAN, or Pascal often do not follow the same calling
convention as C. That is, other languages do not pass argument
and return values between functions in the same way. For this
reason, we will assume that your C-language functions are
actually written in C.
</para>
<para>