Index: doc/src/sgml/docguide.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/docguide.sgml,v
retrieving revision 1.44
diff -c -r1.44 docguide.sgml
*** doc/src/sgml/docguide.sgml 6 Jun 2003 14:17:08 -0000 1.44
--- doc/src/sgml/docguide.sgml 11 Sep 2003 21:01:34 -0000
***************
*** 497,504 ****
Before you can build the documentation you need to run the
configure 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:
checking for onsgmls... onsgmls
--- 497,505 ----
Before you can build the documentation you need to run the
configure 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:
checking for onsgmls... onsgmls
***************
*** 640,646 ****
Print Output via <acronym>RTF</acronym>
! You can also create a printable version of the PostgreSQL
documentation by converting it to RTF and
applying minor formatting corrections using an office suite.
Depending on the capabilities of the particular office suite, you
--- 641,647 ----
Print Output via <acronym>RTF</acronym>
! You can also create a printable version of the PostgreSQL
documentation by converting it to RTF and
applying minor formatting corrections using an office suite.
Depending on the capabilities of the particular office suite, you
***************
*** 651,657 ****
! It appears that current versions of the PostgreSQL documentation
trigger some bug in or exceed the size limit of OpenJade. If the
build process of the RTF version hangs for a
long time and the output file still has size 0, then you may have
--- 652,658 ----
! It appears that current versions of the PostgreSQL documentation
trigger some bug in or exceed the size limit of OpenJade. If the
build process of the RTF version hangs for a
long time and the output file still has size 0, then you may have
Index: doc/src/sgml/ecpg.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/ecpg.sgml,v
retrieving revision 1.50
diff -c -r1.50 ecpg.sgml
*** doc/src/sgml/ecpg.sgml 9 Sep 2003 10:54:44 -0000 1.50
--- doc/src/sgml/ecpg.sgml 11 Sep 2003 21:02:21 -0000
***************
*** 1153,1162 ****
condition. A successful state is indicated by the code
00000. Further information about the codes can
be found XXX. The SQLSTATE codes are for the
! most part defined in the SQL standard. The PostgreSQL server
! natively supports SQLSTATE error codes;
! therefore a high degree of consistency can be achieved by using
! this error code scheme throughout all applications.
--- 1153,1163 ----
condition. A successful state is indicated by the code
00000. Further information about the codes can
be found XXX. The SQLSTATE codes are for the
! most part defined in the SQL standard. The
! PostgreSQL server natively supports
! SQLSTATE error codes; therefore a high degree
! of consistency can be achieved by using this error code scheme
! throughout all applications.
***************
*** 1168,1178 ****
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
! SQLCODE 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
SQLSTATE scheme, the corresponding
SQLSTATE is also listed. There is, however, no
one-to-one or one-to-many mapping between the two schemes (indeed
--- 1169,1179 ----
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 SQLCODE 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
SQLSTATE scheme, the corresponding
SQLSTATE is also listed. There is, however, no
one-to-one or one-to-many mapping between the two schemes (indeed
***************
*** 1291,1299 ****
-208 (ECPG_EMPTY)
! 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)
--- 1292,1301 ----
-208 (ECPG_EMPTY)
! 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)
Index: doc/src/sgml/extend.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/extend.sgml,v
retrieving revision 1.24
diff -c -r1.24 extend.sgml
*** doc/src/sgml/extend.sgml 31 Aug 2003 17:32:18 -0000 1.24
--- doc/src/sgml/extend.sgml 11 Sep 2003 21:02:47 -0000
***************
*** 69,82 ****
! 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 PostgreSQL will load it as required. Code written
! in SQL is even more trivial to add to the server.
! This ability to modify its operation on the fly makes
! PostgreSQL uniquely suited for rapid prototyping of new
! applications and storage structures.
--- 69,84 ----
! 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
! PostgreSQL will load it as required.
! Code written in SQL is even more trivial to add
! to the server. This ability to modify its operation on the
! fly makes PostgreSQL uniquely
! suited for rapid prototyping of new applications and storage
! structures.
Index: doc/src/sgml/features.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/features.sgml,v
retrieving revision 2.18
diff -c -r2.18 features.sgml
*** doc/src/sgml/features.sgml 13 Mar 2003 01:30:28 -0000 2.18
--- doc/src/sgml/features.sgml 11 Sep 2003 21:03:14 -0000
***************
*** 63,73 ****
In the following two sections, we provide a list of those features
that PostgreSQL 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.
--- 63,74 ----
In the following two sections, we provide a list of those features
that PostgreSQL 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.
Index: doc/src/sgml/history.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/history.sgml,v
retrieving revision 1.21
diff -c -r1.21 history.sgml
*** doc/src/sgml/history.sgml 8 Sep 2003 23:02:28 -0000 1.21
--- doc/src/sgml/history.sgml 11 Sep 2003 21:04:01 -0000
***************
*** 206,213 ****
! Details about what has happened in PostgreSQL since then can be
! found in .
--- 206,213 ----
! Details about what has happened in PostgreSQL since
! then can be found in .
Index: doc/src/sgml/indices.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/indices.sgml,v
retrieving revision 1.43
diff -c -r1.43 indices.sgml
*** doc/src/sgml/indices.sgml 31 Aug 2003 17:32:19 -0000 1.43
--- doc/src/sgml/indices.sgml 11 Sep 2003 21:04:25 -0000
***************
*** 194,204 ****
! 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.
--- 194,204 ----
! 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.
Index: doc/src/sgml/information_schema.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/information_schema.sgml,v
retrieving revision 1.6
diff -c -r1.6 information_schema.sgml
*** doc/src/sgml/information_schema.sgml 29 Jun 2003 15:14:41 -0000 1.6
--- doc/src/sgml/information_schema.sgml 11 Sep 2003 21:10:04 -0000
***************
*** 12,22 ****
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
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.
--- 12,24 ----
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
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.
***************
*** 319,330 ****
! In PostgreSQL, you can only grant privileges on entire tables, not
! individual columns. Therefore, this view contains the same
! information as table_privileges, just
! represented through one row for each column in each appropriate
! table, but it only convers privilege types where column granularity
! is possible: SELECT, INSERT,
UPDATE, REFERENCES. If you
want to make your applications fit for possible future
developements, it is generally the right choice to use this view
--- 321,333 ----
! In PostgreSQL, you can only grant
! privileges on entire tables, not individual columns. Therefore,
! this view contains the same information as
! table_privileges, just represented through one
! row for each column in each appropriate table, but it only convers
! privilege types where column granularity is possible:
! SELECT, INSERT,
UPDATE, REFERENCES. If you
want to make your applications fit for possible future
developements, it is generally the right choice to use this view
***************
*** 404,411 ****
Note that the column grantee 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.
--- 407,414 ----
Note that the column grantee 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.
***************
*** 415,423 ****
The view column_udt_usage 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 for details.
--- 418,426 ----
The view column_udt_usage 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 for details.
***************
*** 595,601 ****
If data_type 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
other data types.
--- 598,604 ----
If data_type 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
other data types.
***************
*** 800,823 ****
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 data_type 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
pg_catalog. 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 udt_name,
udt_schema, and udt_catalog
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
domain_name, domain_schema,
and domain_catalog. If you want to pair up
columns with their associated data types and treat domains as
--- 803,828 ----
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 data_type
! 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
pg_catalog. 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 udt_name,
udt_schema, and udt_catalog
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
domain_name, domain_schema,
and domain_catalog. If you want to pair up
columns with their associated data types and treat domains as
***************
*** 1141,1148 ****
The view domain_udt_usage 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.
--- 1146,1153 ----
The view domain_udt_usage 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.
***************
*** 1266,1272 ****
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.
--- 1271,1278 ----
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.
***************
*** 2416,2426 ****
The view role_usage_grants is meant to identify
USAGE 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
! usage_privileges. In the future, this view may
! contain more useful information.
--- 2422,2432 ----
The view role_usage_grants is meant to identify
USAGE 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 usage_privileges.
! In the future, this view may contain more useful information.
***************
*** 2582,2589 ****
Note that the column grantee 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.
--- 2588,2595 ----
Note that the column grantee 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.
***************
*** 2874,2881 ****
not the owner of the function). (According to the SQL
standard, this column is only applicable if
routine_body is SQL, but
! in PostgreSQL it will contain whatever source text was
! specified when the function was created.)
--- 2880,2888 ----
not the owner of the function). (According to the SQL
standard, this column is only applicable if
routine_body is SQL, but
! in PostgreSQL it will contain
! whatever source text was specified when the function was
! created.)
***************
*** 3082,3090 ****
The table sql_features contains information
about which formal features defined in the SQL standard are
! supported by PostgreSQL. This is the same information that is
! presented in . There you can also find
! some additional background information.
--- 3089,3097 ----
The table sql_features contains information
about which formal features defined in the SQL standard are
! supported by PostgreSQL. This is the
! same information that is presented in .
! There you can also find some additional background information.
***************
*** 3226,3234 ****
The table sql_languages 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.
--- 3233,3242 ----
The table sql_languages 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.
***************
*** 3313,3320 ****
The table sql_packages contains information
about which features packages defined in the SQL standard are
! supported by PostgreSQL. Refer to for
! background information on feature packages.
--- 3321,3328 ----
The table sql_packages contains information
about which features packages defined in the SQL standard are
! supported by PostgreSQL. Refer to for background information on feature packages.
***************
*** 3375,3386 ****
The table sql_sizing 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.
--- 3383,3395 ----
The table sql_sizing 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.
***************
*** 3657,3664 ****
Note that the column grantee 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.
--- 3666,3673 ----
Note that the column grantee 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.
***************
*** 3875,3895 ****
! 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
than independent schema objects. Therefore there may be duplicate
trigger names defined in one schema, as long as they belong to
different tables. (trigger_catalog and
trigger_schema 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.,
! ON INSERT OR UPDATE), 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 triggers is
! really (trigger_catalog, trigger_schema, trigger_name,
event_object_name, event_manipulation) instead of
(trigger_catalog, trigger_schema, trigger_name),
which is what the SQL standard specifies. Nonetheless, if you
--- 3884,3906 ----
! 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
than independent schema objects. Therefore there may be duplicate
trigger names defined in one schema, as long as they belong to
different tables. (trigger_catalog and
trigger_schema 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., ON INSERT OR
! UPDATE), 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 triggers is really
! (trigger_catalog, trigger_schema, trigger_name,
event_object_name, event_manipulation) instead of
(trigger_catalog, trigger_schema, trigger_name),
which is what the SQL standard specifies. Nonetheless, if you
***************
*** 3905,3913 ****
The view usage_privileges is meant to identify
USAGE 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
USAGE privileges granted to
PUBLIC for all domains. In the future, this
view may contain more useful information.
--- 3916,3925 ----
The view usage_privileges is meant to identify
USAGE 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
USAGE privileges granted to
PUBLIC for all domains. In the future, this
view may contain more useful information.
Index: doc/src/sgml/installation.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/installation.sgml,v
retrieving revision 1.140
diff -c -r1.140 installation.sgml
*** doc/src/sgml/installation.sgml 1 Sep 2003 23:01:49 -0000 1.140
--- doc/src/sgml/installation.sgml 11 Sep 2003 21:10:45 -0000
***************
*** 406,418 ****
To make the backup, you can use the pg_dumpall
command from the version you are currently running. For best
results, however, try to use the pg_dumpall
! 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.
--- 406,419 ----
To make the backup, you can use the pg_dumpall
command from the version you are currently running. For best
results, however, try to use the pg_dumpall
! 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.
Index: doc/src/sgml/intro.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/intro.sgml,v
retrieving revision 1.21
diff -c -r1.21 intro.sgml
*** doc/src/sgml/intro.sgml 8 Sep 2003 23:02:28 -0000 1.21
--- doc/src/sgml/intro.sgml 11 Sep 2003 21:11:59 -0000
***************
*** 6,23 ****
Preface
! 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.
! 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:
--- 6,26 ----
Preface
! 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.
! 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:
***************
*** 38,53 ****
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.
describes the programming
! interfaces for PostgreSQL client programs.
--- 41,57 ----
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.
describes the programming
! interfaces for PostgreSQL client
! programs.
***************
*** 111,118 ****
! Also, PostgreSQL can be extended by the user in many ways, for
! example by adding new
--- 115,122 ----
! Also, PostgreSQL can be extended by the
! user in many ways, for example by adding new
***************
*** 137,145 ****
! 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.
--- 141,150 ----
! 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.
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/libpq.sgml,v
retrieving revision 1.135
diff -c -r1.135 libpq.sgml
*** doc/src/sgml/libpq.sgml 3 Sep 2003 22:05:01 -0000 1.135
--- doc/src/sgml/libpq.sgml 11 Sep 2003 21:12:45 -0000
***************
*** 2049,2059 ****
from parameter binary string in memory
allocated with malloc(). This memory must be freed
using 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 bytea 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.
--- 2049,2061 ----
from parameter binary string in memory
allocated with malloc(). This memory must be freed
using 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 bytea 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.
Index: doc/src/sgml/plpgsql.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.24
diff -c -r1.24 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml 11 Sep 2003 18:30:38 -0000 1.24
--- doc/src/sgml/plpgsql.sgml 11 Sep 2003 21:13:41 -0000
***************
*** 2056,2064 ****
(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
! and
! configuration variables. See
! for more information.
--- 2056,2065 ----
(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
! log_min_messages and
! client_min_messages configuration
! variables. See for more
! information.
***************
*** 2448,2454 ****
The RETURN key word in the function
prototype (not the function body) becomes
! RETURNS in PostgreSQL.
--- 2449,2456 ----
The RETURN key word in the function
prototype (not the function body) becomes
! RETURNS in
! PostgreSQL.
***************
*** 2805,2811 ****
This section explains a few other things to watch for when porting
! Oracle PL/SQL functions to PostgreSQL.
--- 2807,2814 ----
This section explains a few other things to watch for when porting
! Oracle PL/SQL functions to
! PostgreSQL.
Index: doc/src/sgml/protocol.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/protocol.sgml,v
retrieving revision 1.43
diff -c -r1.43 protocol.sgml
*** doc/src/sgml/protocol.sgml 3 Sep 2003 22:05:07 -0000 1.43
--- doc/src/sgml/protocol.sgml 11 Sep 2003 21:14:26 -0000
***************
*** 4,10 ****
Frontend/Backend Protocol
! PostgreSQL uses a message-based protocol
for communication between frontends and backends (clients and servers).
The protocol is supported over TCP/IP and also over
Unix-domain sockets. Port number 5432 has been registered with IANA as
--- 4,10 ----
Frontend/Backend Protocol
! PostgreSQL uses a message-based protocol
for communication between frontends and backends (clients and servers).
The protocol is supported over TCP/IP and also over
Unix-domain sockets. Port number 5432 has been registered with IANA as
***************
*** 14,20 ****
This document describes version 3.0 of the protocol, implemented in
! PostgreSQL 7.4 and later. For descriptions
of the earlier protocol versions, see previous releases of the
PostgreSQL documentation. A single server
can support multiple protocol versions. The initial
--- 14,20 ----
This document describes version 3.0 of the protocol, implemented in
! PostgreSQL 7.4 and later. For descriptions
of the earlier protocol versions, see previous releases of the
PostgreSQL documentation. A single server
can support multiple protocol versions. The initial
***************
*** 165,171 ****
Data of a particular datatype might be transmitted in any of several
! different formats. As of PostgreSQL 7.4
the only supported formats are text and binary,
but the protocol makes provision for future extensions. The desired
format for any value is specified by a format code.
--- 165,171 ----
Data of a particular datatype might be transmitted in any of several
! different formats. As of PostgreSQL 7.4
the only supported formats are text and binary,
but the protocol makes provision for future extensions. The desired
format for any value is specified by a format code.
Index: doc/src/sgml/release.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/release.sgml,v
retrieving revision 1.206
diff -c -r1.206 release.sgml
*** doc/src/sgml/release.sgml 27 Aug 2003 03:35:35 -0000 1.206
--- doc/src/sgml/release.sgml 11 Sep 2003 21:21:41 -0000
***************
*** 10,17 ****
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.