mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-01-24 18:55:04 +08:00
Deprecate 'current' date/time constant.
Purge "Postgres" in favor of "PostgreSQL" in docs. ref/ not yet done.
This commit is contained in:
Thomas G. Lockhart
parent
90e757c17d
commit
6c402eafc8
@ -1,5 +1,5 @@
|
||||
<!-- reference.sgml
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/reference.sgml,v 1.18 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/reference.sgml,v 1.19 2001/11/21 06:09:44 thomas Exp $
|
||||
|
||||
PostgreSQL Reference Manual
|
||||
-->
|
||||
@ -128,7 +128,7 @@ Disable this chapter until we have more functions documented.
|
||||
<para>
|
||||
This part provides reference information for the
|
||||
<acronym>SQL</acronym> functions supported by
|
||||
<productname>Postgres</productname>.
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
¤tDate;
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.103 2001/11/08 23:42:23 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.104 2001/11/21 06:09:44 thomas Exp $
|
||||
-->
|
||||
|
||||
<appendix id="release">
|
||||
@ -829,7 +829,7 @@ ecpg changes (Michael)
|
||||
<para>
|
||||
A dump/restore using <application>pg_dump</application>
|
||||
is required for those wishing to migrate data from any
|
||||
previous release of <productname>Postgres</productname>.
|
||||
previous release of <productname>PostgreSQL</productname>.
|
||||
For those upgrading from 6.5.*, you may instead use
|
||||
<application>pg_upgrade</application> to upgrade to this
|
||||
release; however, a full dump/reload installation is always the
|
||||
@ -848,7 +848,7 @@ ecpg changes (Michael)
|
||||
SQL92-defined types <type>timestamp</type> and
|
||||
<type>interval</type>. Although there has been some effort to
|
||||
ease the transition by allowing
|
||||
<productname>Postgres</productname> to recognize
|
||||
<productname>PostgreSQL</productname> to recognize
|
||||
the deprecated type names and translate them to the new type
|
||||
names, this mechanism may not be completely transparent to
|
||||
your existing application.
|
||||
@ -1554,7 +1554,7 @@ Add Win1250 (Czech) support (Pavel Behal)
|
||||
chapter on troubleshooting from Tom Lane.
|
||||
And the <citetitle>Programmer's Guide</citetitle> has a
|
||||
description of query processing, also from Stefan, and details
|
||||
on obtaining the <productname>Postgres</productname> source
|
||||
on obtaining the <productname>PostgreSQL</productname> source
|
||||
tree via anonymous <productname>CVS</productname> and
|
||||
<productname>CVSup</productname>.
|
||||
</para>
|
||||
@ -1569,7 +1569,7 @@ Add Win1250 (Czech) support (Pavel Behal)
|
||||
<para>
|
||||
A dump/restore using <application>pg_dump</application>
|
||||
is required for those wishing to migrate data from any
|
||||
previous release of <productname>Postgres</productname>.
|
||||
previous release of <productname>PostgreSQL</productname>.
|
||||
<application>pg_upgrade</application> can <emphasis>not</emphasis>
|
||||
be used to upgrade to this release because the on-disk structure
|
||||
of the tables has changed compared to previous releases.
|
||||
@ -1602,7 +1602,7 @@ Add Win1250 (Czech) support (Pavel Behal)
|
||||
concurrent updates one must use <command>SELECT FOR UPDATE</command> or
|
||||
an appropriate <command>LOCK TABLE</command> statement. This should be
|
||||
taken into account when porting applications from previous releases of
|
||||
<productname>Postgres</productname> and other environments.
|
||||
<productname>PostgreSQL</productname> and other environments.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1986,7 +1986,7 @@ asynchronous messages and interrupts thanks to Tom Lane.
|
||||
The parser will now perform automatic type coercion to match arguments
|
||||
to available operators and functions, and to match columns and expressions
|
||||
with target columns. This uses a generic mechanism which supports
|
||||
the type extensibility features of <productname>Postgres</productname>.
|
||||
the type extensibility features of <productname>PostgreSQL</productname>.
|
||||
There is a new chapter in the <citetitle>User's Guide</citetitle>
|
||||
which covers this topic.
|
||||
</para>
|
||||
@ -2029,7 +2029,7 @@ been.
|
||||
A dump/restore using <application>pg_dump</application>
|
||||
or <application>pg_dumpall</application>
|
||||
is required for those wishing to migrate data from any
|
||||
previous release of <productname>Postgres</productname>.
|
||||
previous release of <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -2281,7 +2281,7 @@ Correctly handles function calls on the left side of BETWEEN and LIKE clauses.
|
||||
A dump/restore is NOT required for those running 6.3 or 6.3.1. A
|
||||
<literal>make distclean</>, <literal>make</>, and <literal>make install</> is all that is required.
|
||||
This last step should be performed while the postmaster is not running.
|
||||
You should re-link any custom applications that use <productname>Postgres</productname> libraries.
|
||||
You should re-link any custom applications that use <productname>PostgreSQL</productname> libraries.
|
||||
</para>
|
||||
<para>
|
||||
For upgrades from pre-6.3 installations,
|
||||
@ -2369,7 +2369,7 @@ Improvements to the configuration autodetection for installation.
|
||||
A dump/restore is NOT required for those running 6.3. A
|
||||
<literal>make distclean</>, <literal>make</>, and <literal>make install</> is all that is required.
|
||||
This last step should be performed while the postmaster is not running.
|
||||
You should re-link any custom applications that use <productname>Postgres</productname> libraries.
|
||||
You should re-link any custom applications that use <productname>PostgreSQL</productname> libraries.
|
||||
</para>
|
||||
<para>
|
||||
For upgrades from pre-6.3 installations,
|
||||
@ -2542,7 +2542,7 @@ Better identify tcl and tk libs and includes(Bruce)
|
||||
\d command for types, operators, etc. Also, views have their own
|
||||
permissions now, not based on the underlying tables, so permissions on
|
||||
them have to be set separately. Check <filename>/pgsql/interfaces</filename> for some new
|
||||
ways to talk to <productname>Postgres</productname>.
|
||||
ways to talk to <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
<para>
|
||||
This is the first release that really required an explanation for
|
||||
@ -2558,7 +2558,7 @@ Better identify tcl and tk libs and includes(Bruce)
|
||||
A dump/restore using <application>pg_dump</application>
|
||||
or <application>pg_dumpall</application>
|
||||
is required for those wishing to migrate data from any
|
||||
previous release of <productname>Postgres</productname>.
|
||||
previous release of <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -2615,7 +2615,7 @@ Modify constraint syntax to be SQL92-compliant(Thomas)
|
||||
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indexes(Thomas)
|
||||
Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
|
||||
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
|
||||
Allow Postgres-style casting ("::") of non-constants(Thomas)
|
||||
Allow PostgreSQL-style casting ("::") of non-constants(Thomas)
|
||||
Add support for SQL3 TRUE and FALSE boolean constants(Thomas)
|
||||
Support SQL92 syntax for IS TRUE/IS FALSE/IS NOT TRUE/IS NOT FALSE(Thomas)
|
||||
Allow shorter strings for boolean literals (e.g. "t", "tr", "tru")(Thomas)
|
||||
@ -2628,7 +2628,7 @@ Use shared lock when building indexes(Vadim)
|
||||
Free memory allocated for an user query inside transaction block after
|
||||
this query is done, was turned off in <= 6.2.1(Vadim)
|
||||
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
|
||||
New <productname>Postgres</productname> Procedural Language (PL) backend interface(Jan)
|
||||
New <productname>PostgreSQL</productname> Procedural Language (PL) backend interface(Jan)
|
||||
Rename pg_dump -H option to -h(Bruce)
|
||||
Add Java support for passwords, European dates(Peter)
|
||||
Use indexes for LIKE and ~, !~ operations(Bruce)
|
||||
@ -2637,7 +2637,7 @@ Time Travel removed(Vadim, Bruce)
|
||||
Add paging for \d and \z, and fix \i(Bruce)
|
||||
Add Unix domain socket support to backend and to frontend library(Goran)
|
||||
Implement CREATE DATABASE/WITH LOCATION and initlocation utility(Thomas)
|
||||
Allow more SQL92 and/or <productname>Postgres</productname> reserved words as column identifiers(Thomas)
|
||||
Allow more SQL92 and/or <productname>PostgreSQL</productname> reserved words as column identifiers(Thomas)
|
||||
Augment support for SQL92 SET TIME ZONE...(Thomas)
|
||||
SET/SHOW/RESET TIME ZONE uses TZ backend environment variable(Thomas)
|
||||
Implement SET keyword = DEFAULT and SET TIME ZONE DEFAULT(Thomas)
|
||||
@ -2850,7 +2850,7 @@ Trigger function for inserting user names for INSERT/UPDATE(Brook Milligan)
|
||||
|
||||
<para>
|
||||
A dump/restore is required for those wishing to migrate data from
|
||||
previous releases of <productname>Postgres</productname>.
|
||||
previous releases of <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
@ -3071,19 +3071,19 @@ pg_dumpall now returns proper status, portability fix(Bruce)
|
||||
|
||||
<para>
|
||||
The regression tests have been adapted and extensively modified for the
|
||||
6.1 release of <productname>Postgres</productname>.
|
||||
6.1 release of <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Three new data types (<type>datetime</type>, <type>timespan</type>, and <type>circle</type>) have been added to
|
||||
the native set of <productname>Postgres</productname> types. Points, boxes, paths, and polygons
|
||||
the native set of <productname>PostgreSQL</productname> types. Points, boxes, paths, and polygons
|
||||
have had their output formats made consistent across the data types.
|
||||
The polygon output in misc.out has only been spot-checked for correctness
|
||||
relative to the original regression output.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> 6.1 introduces a new, alternate
|
||||
<productname>PostgreSQL</productname> 6.1 introduces a new, alternate
|
||||
optimizer which uses <firstterm>genetic</firstterm>
|
||||
algorithms. These algorithms introduce a random behavior in the ordering
|
||||
of query results when the query contains multiple qualifiers or multiple
|
||||
@ -3253,7 +3253,7 @@ DG-UX, Ultrix, Irix, AIX portability fixes
|
||||
|
||||
<para>
|
||||
A dump/restore is required for those wishing to migrate data from
|
||||
previous releases of <productname>Postgres</productname>.
|
||||
previous releases of <productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.18 2001/11/12 19:19:39 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.19 2001/11/21 06:09:45 thomas Exp $ -->
|
||||
|
||||
<Chapter Id="rules">
|
||||
<Title>The Rule System</Title>
|
||||
@ -18,7 +18,7 @@
|
||||
Production rule systems are conceptually simple, but
|
||||
there are many subtle points involved in actually using
|
||||
them. Some of these points and
|
||||
the theoretical foundations of the <ProductName>Postgres</ProductName>
|
||||
the theoretical foundations of the <ProductName>PostgreSQL</ProductName>
|
||||
rule system can be found in
|
||||
<XRef LinkEnd="STON90b">.
|
||||
</Para>
|
||||
@ -26,7 +26,7 @@
|
||||
<Para>
|
||||
Some other database systems define active database rules. These
|
||||
are usually stored procedures and triggers and are implemented
|
||||
in <ProductName>Postgres</ProductName> as functions and triggers.
|
||||
in <ProductName>PostgreSQL</ProductName> as functions and triggers.
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
@ -64,7 +64,7 @@
|
||||
Now what is a query tree? It is an internal representation of an
|
||||
<Acronym>SQL</Acronym> statement where the single parts that built
|
||||
it are stored separately. These query trees are visible when starting
|
||||
the <ProductName>Postgres</ProductName> backend with debug level 4
|
||||
the <ProductName>PostgreSQL</ProductName> backend with debug level 4
|
||||
and typing queries into the interactive backend interface. The rule
|
||||
actions in the <FileName>pg_rewrite</FileName> system catalog are
|
||||
also stored as query trees. They are not formatted like the debug
|
||||
@ -268,10 +268,10 @@
|
||||
<indexterm zone="rules-views"><primary>rules</><secondary>and views</></>
|
||||
|
||||
<Sect2>
|
||||
<Title>Implementation of Views in <ProductName>Postgres</ProductName></Title>
|
||||
<Title>Implementation of Views in <ProductName>PostgreSQL</ProductName></Title>
|
||||
|
||||
<Para>
|
||||
Views in <ProductName>Postgres</ProductName> are implemented
|
||||
Views in <ProductName>PostgreSQL</ProductName> are implemented
|
||||
using the rule system. In fact there is absolutely no difference
|
||||
between a
|
||||
|
||||
@ -289,7 +289,7 @@
|
||||
|
||||
because this is exactly what the CREATE VIEW command does internally.
|
||||
This has some side effects. One of them is that
|
||||
the information about a view in the <ProductName>Postgres</ProductName>
|
||||
the information about a view in the <ProductName>PostgreSQL</ProductName>
|
||||
system catalogs is exactly the same as it is for a table. So for the
|
||||
query parser, there is absolutely no difference between
|
||||
a table and a view. They are the same thing - relations. That is the
|
||||
@ -785,7 +785,7 @@
|
||||
SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
|
||||
</ProgramListing>
|
||||
|
||||
Now another detail of <ProductName>Postgres</ProductName> enters the
|
||||
Now another detail of <ProductName>PostgreSQL</ProductName> enters the
|
||||
stage. At this moment, table rows aren't overwritten and this is why
|
||||
ABORT TRANSACTION is fast. In an UPDATE, the new result row is inserted
|
||||
into the table (after stripping ctid) and in the tuple header of the row
|
||||
@ -802,7 +802,7 @@
|
||||
</Sect2>
|
||||
|
||||
<Sect2>
|
||||
<Title>The Power of Views in <ProductName>Postgres</ProductName></Title>
|
||||
<Title>The Power of Views in <ProductName>PostgreSQL</ProductName></Title>
|
||||
|
||||
<Para>
|
||||
The above demonstrates how the rule system incorporates
|
||||
@ -826,7 +826,7 @@
|
||||
Now the planner has to decide which is
|
||||
the best path to execute the query. The more information
|
||||
the planner has, the better this decision can be. And
|
||||
the rule system as implemented in <ProductName>Postgres</ProductName>
|
||||
the rule system as implemented in <ProductName>PostgreSQL</ProductName>
|
||||
ensures, that this is all information available about the query
|
||||
up to now.
|
||||
</Para>
|
||||
@ -1604,7 +1604,7 @@ Merge Join
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
A final demonstration of the <ProductName>Postgres</ProductName>
|
||||
A final demonstration of the <ProductName>PostgreSQL</ProductName>
|
||||
rule system and its power. There is a cute blonde that
|
||||
sells shoelaces. And what Al could never realize, she's not
|
||||
only cute, she's smart too - a little too smart. Thus, it
|
||||
@ -1644,7 +1644,7 @@ Merge Join
|
||||
|
||||
For the 1000 magenta shoelaces we must debt Al before we can
|
||||
throw 'em away, but that's another problem. The pink entry we delete.
|
||||
To make it a little harder for <ProductName>Postgres</ProductName>,
|
||||
To make it a little harder for <ProductName>PostgreSQL</ProductName>,
|
||||
we don't delete it directly. Instead we create one more view
|
||||
|
||||
<ProgramListing>
|
||||
@ -1708,7 +1708,7 @@ Merge Join
|
||||
<Title>Rules and Permissions</Title>
|
||||
|
||||
<Para>
|
||||
Due to rewriting of queries by the <ProductName>Postgres</ProductName>
|
||||
Due to rewriting of queries by the <ProductName>PostgreSQL</ProductName>
|
||||
rule system, other tables/views than those used in the original
|
||||
query get accessed. Using update rules, this can include write access
|
||||
to tables.
|
||||
@ -1718,7 +1718,7 @@ Merge Join
|
||||
Rewrite rules don't have a separate owner. The owner of
|
||||
a relation (table or view) is automatically the owner of the
|
||||
rewrite rules that are defined for it.
|
||||
The <ProductName>Postgres</ProductName> rule system changes the
|
||||
The <ProductName>PostgreSQL</ProductName> rule system changes the
|
||||
behavior of the default access control system. Relations that
|
||||
are used due to rules get checked against the
|
||||
permissions of the rule owner, not the user invoking the rule.
|
||||
@ -1798,7 +1798,7 @@ Merge Join
|
||||
|
||||
<Para>
|
||||
Many things that can be done using triggers can also be
|
||||
implemented using the <ProductName>Postgres</ProductName>
|
||||
implemented using the <ProductName>PostgreSQL</ProductName>
|
||||
rule system. What currently cannot be implemented by
|
||||
rules are some kinds of constraints. It is possible,
|
||||
to place a qualified rule that rewrites a query to NOTHING
|
||||
@ -1971,7 +1971,7 @@ Merge Join
|
||||
<Para>
|
||||
Another situation is cases on UPDATE where it depends on the
|
||||
change of an attribute if an action should be performed or
|
||||
not. In <ProductName>Postgres</ProductName> version 6.4, the
|
||||
not. In <ProductName>PostgreSQL</ProductName> version 6.4, the
|
||||
attribute specification for rule events is disabled (it will have
|
||||
its comeback latest in 6.5, maybe earlier
|
||||
- stay tuned). So for now the only way to
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.97 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
|
||||
</para>
|
||||
|
||||
<sect1 id="postgres-user">
|
||||
<title>The Postgres user account</title>
|
||||
<title>The <productname>PostgreSQL</productname> user account</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>postgres user</primary>
|
||||
@ -19,7 +19,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
|
||||
|
||||
<para>
|
||||
As with any other server daemon that is connected to the world at
|
||||
large, it is advisable to run Postgres under a separate user
|
||||
large, it is advisable to run <productname>PostgreSQL</productname> under a separate user
|
||||
account. This user account should only own the data itself that is
|
||||
being managed by the server, and should not be shared with other
|
||||
daemons. (Thus, using the user <quote>nobody</quote> is a bad
|
||||
@ -77,7 +77,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
|
||||
> <userinput>initdb -D /usr/local/pgsql/data</userinput>
|
||||
</screen>
|
||||
Note that you must execute this command while being logged in to
|
||||
the Postgres user account, which is described in the previous
|
||||
the <productname>PostgreSQL</productname> user account, which is described in the previous
|
||||
section.
|
||||
</para>
|
||||
|
||||
@ -97,7 +97,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
|
||||
have the permission to do so (if you followed our advice and
|
||||
created an unprivileged account). In that case you should create the
|
||||
directory yourself (as root) and transfer ownership of it to the
|
||||
Postgres user account. Here is how this might work:
|
||||
<productname>PostgreSQL</productname> user account. Here is how this might work:
|
||||
<screen>
|
||||
root# <userinput>mkdir /usr/local/pgsql/data</userinput>
|
||||
root# <userinput>chown postgres /usr/local/pgsql/data</userinput>
|
||||
@ -115,7 +115,7 @@ postgres> <userinput>initdb -D /usr/local/pgsql/data</userinput>
|
||||
Because the data directory contains all the data stored in the
|
||||
database it is essential that it be well secured from unauthorized
|
||||
access. <command>initdb</command> therefore revokes access
|
||||
permissions from everyone but the Postgres user account.
|
||||
permissions from everyone but the <productname>PostgreSQL</productname> user account.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -159,7 +159,7 @@ NOTICE: Initializing database with en_US collation order.
|
||||
> <userinput>postmaster -D /usr/local/pgsql/data</userinput>
|
||||
</screen>
|
||||
which will leave the server running in the foreground. This must
|
||||
again be done while logged in to the Postgres user account. Without
|
||||
again be done while logged in to the <productname>PostgreSQL</productname> user account. Without
|
||||
a <option>-D</option>, the server will try to use the data
|
||||
directory in the environment variable <envar>PGDATA</envar>; if
|
||||
neither of these works it will fail.
|
||||
@ -221,7 +221,7 @@ pg_ctl start -l logfile
|
||||
<filename>/etc/rc.local</filename> or
|
||||
<filename>/etc/rc.d/rc.local</filename> which is almost certainly
|
||||
no bad place to put such a command. Whatever you do, the server
|
||||
must be run by the <productname>Postgres</productname> user account
|
||||
must be run by the <productname>PostgreSQL</productname> user account
|
||||
<emphasis>and not by root</emphasis> or any other user. Therefore
|
||||
you probably always want to form your command lines along the lines
|
||||
of <literal>su -c '...' postgres</literal>, for example:
|
||||
@ -347,7 +347,7 @@ IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argum
|
||||
FATAL 1: ShmemCreate: cannot create region
|
||||
</screen>
|
||||
probably means that your kernel's limit on the size of shared
|
||||
memory areas is smaller than the buffer area that Postgres is
|
||||
memory areas is smaller than the buffer area that <productname>PostgreSQL</productname> is
|
||||
trying to create (83918612 bytes in this example). Or it could
|
||||
mean that you don't have System-V-style shared memory support
|
||||
configured into your kernel at all. As a temporary workaround,
|
||||
@ -367,7 +367,7 @@ IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on
|
||||
does <emphasis>not</emphasis> mean that you've run out of disk
|
||||
space; it means that your kernel's limit on the number of System
|
||||
V semaphores is smaller than the number
|
||||
<productname>Postgres</productname> wants to create. As above,
|
||||
<productname>PostgreSQL</productname> wants to create. As above,
|
||||
you may be able to work around the problem by starting the
|
||||
postmaster with a reduced number of backend processes
|
||||
(<option>-N</option> switch), but you'll eventually want to
|
||||
@ -574,7 +574,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
Sets the optimizer's assumption about the effective size of
|
||||
the disk cache (that is, the portion of the kernel's disk
|
||||
cache that will be used for
|
||||
<productname>Postgres</productname> data files). This is
|
||||
<productname>PostgreSQL</productname> data files). This is
|
||||
measured in disk pages, which are normally 8 kB apiece.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -756,7 +756,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<para>
|
||||
The <acronym>KSQO</acronym> algorithm used to be absolutely essential for queries
|
||||
with many OR'ed AND clauses, but in
|
||||
<productname>Postgres</productname> 7.0 and later the standard
|
||||
<productname>PostgreSQL</productname> 7.0 and later the standard
|
||||
planner handles these queries fairly successfully. Hence the
|
||||
default is OFF.
|
||||
</para>
|
||||
@ -800,9 +800,9 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
you are experiencing strange problems or crashes you might
|
||||
want to turn this on, as it might expose programming mistakes.
|
||||
To use this option, the macro <literal>USE_ASSERT_CHECKING</literal>
|
||||
must be defined when Postgres is built (see the configure option
|
||||
must be defined when <productname>PostgreSQL</productname> is built (see the configure option
|
||||
<literal>--enable-cassert</literal>). Note that
|
||||
<literal>DEBUG_ASSERTIONS</literal> defaults to ON if Postgres
|
||||
<literal>DEBUG_ASSERTIONS</literal> defaults to ON if <productname>PostgreSQL</productname>
|
||||
has been built this way.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -957,7 +957,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<term><varname>SYSLOG</varname> (<type>integer</type>)</term>
|
||||
<listitem>
|
||||
<para>
|
||||
<productname>Postgres</productname> allows the use of
|
||||
<productname>PostgreSQL</productname> allows the use of
|
||||
<systemitem>syslog</systemitem> for logging. If this option
|
||||
is set to 1, messages go both to <systemitem>syslog</> and the standard
|
||||
output. A setting of 2 sends output only to <systemitem>syslog</>. (Some
|
||||
@ -967,7 +967,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
</para>
|
||||
<para>
|
||||
To use <systemitem>syslog</>, the build of
|
||||
<productname>Postgres</productname> must be configured with
|
||||
<productname>PostgreSQL</productname> must be configured with
|
||||
the <option>--enable-syslog</option> option.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1121,8 +1121,8 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
The value for dynamic_library_path has to be a colon-separated
|
||||
list of absolute directory names. If a directory name starts
|
||||
with the special value <literal>$libdir</literal>, the
|
||||
compiled-in PostgreSQL package library directory, which is where the
|
||||
modules provided by the PostgreSQL distribution are installed,
|
||||
compiled-in <productname>PostgreSQL</productname> package library directory, which is where the
|
||||
modules provided by the <productname>PostgreSQL</productname> distribution are installed,
|
||||
is substituted. (Use <literal>pg_config --pkglibdir</literal>
|
||||
to print the name of this directory.) An example value:
|
||||
<informalexample>
|
||||
@ -1157,7 +1157,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<term><varname>FSYNC</varname> (<type>boolean</type>)</term>
|
||||
<listitem>
|
||||
<para>
|
||||
If this option is on, the <productname>Postgres</> backend
|
||||
If this option is on, the <productname>PostgreSQL</> backend
|
||||
will use the <function>fsync()</> system call in several
|
||||
places to make sure that updates are physically written to
|
||||
disk and do not hang around in the kernel buffer cache. This
|
||||
@ -1168,7 +1168,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
However, this operation slows down <productname>Postgres</>,
|
||||
However, this operation slows down <productname>PostgreSQL</>,
|
||||
because at all those points it has
|
||||
to block and wait for the operating system to flush the
|
||||
buffers. Without <function>fsync</>, the operating system is
|
||||
@ -1181,7 +1181,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<para>
|
||||
This option is the subject of an eternal debate in the
|
||||
<productname>Postgres</> user and developer communities. Some
|
||||
<productname>PostgreSQL</> user and developer communities. Some
|
||||
always leave it off, some turn it off only for bulk loads,
|
||||
where there is a clear restart point if something goes wrong,
|
||||
some leave it on just to be on the safe side. Because it is
|
||||
@ -1192,7 +1192,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<para>
|
||||
It should be noted that the performance penalty from doing
|
||||
fsyncs is considerably less in <productname>Postgres</> version
|
||||
fsyncs is considerably less in <productname>PostgreSQL</> version
|
||||
7.1 than it was in prior releases. If you previously suppressed
|
||||
fsyncs because of performance problems, you may wish to reconsider
|
||||
your choice.
|
||||
@ -1766,7 +1766,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<title>Managing Kernel Resources</title>
|
||||
|
||||
<para>
|
||||
A large <productname>Postgres</> installation can quickly hit
|
||||
A large <productname>PostgreSQL</> installation can quickly hit
|
||||
various operating system resource limits. (On some systems, the
|
||||
factory defaults are so low that you don't even need a really
|
||||
<quote>large</> installation.) If you have encountered this kind of
|
||||
@ -1787,11 +1787,11 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<para>
|
||||
Shared memory and semaphores are collectively referred to as
|
||||
<quote><systemitem class="osname">System V</> <acronym>IPC</></quote> (together with message queues, which are
|
||||
not relevant for <productname>Postgres</>). Almost all modern
|
||||
not relevant for <productname>PostgreSQL</>). Almost all modern
|
||||
operating systems provide these features, but not all of them have
|
||||
them turned on or sufficiently sized by default, especially
|
||||
systems with BSD heritage. (For the <systemitem class="osname">QNX</> and <systemitem class="osname">BeOS</> ports,
|
||||
<productname>Postgres</> provides its own replacement
|
||||
<productname>PostgreSQL</> provides its own replacement
|
||||
implementation of these facilities.)
|
||||
</para>
|
||||
|
||||
@ -1799,11 +1799,11 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
The complete lack of these facilities is usually manifested by an
|
||||
<errorname>Illegal system call</> error upon postmaster start. In
|
||||
that case there's nothing left to do but to reconfigure your
|
||||
kernel -- <productname>Postgres</> won't work without them.
|
||||
kernel -- <productname>PostgreSQL</> won't work without them.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When <productname>Postgres</> exceeds one of the various hard
|
||||
When <productname>PostgreSQL</> exceeds one of the various hard
|
||||
limits of the <acronym>IPC</> resources then the postmaster will refuse to
|
||||
start up and should leave a marginally instructive error message
|
||||
about which problem was encountered and what needs to be done
|
||||
@ -1917,7 +1917,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<para>
|
||||
Less likely to cause problems is the minimum size for shared
|
||||
memory segments (<varname>SHMMIN</>), which should be at most
|
||||
somewhere around 256 kB for <productname>Postgres</> (it is
|
||||
somewhere around 256 kB for <productname>PostgreSQL</> (it is
|
||||
usually just 1). The maximum number of segments system-wide
|
||||
(<varname>SHMMNI</>) or per-process (<varname>SHMSEG</>) should
|
||||
not cause a problem unless your system has them set to zero. Some
|
||||
@ -1926,7 +1926,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</> uses one semaphore per allowed connection
|
||||
<productname>PostgreSQL</> uses one semaphore per allowed connection
|
||||
(<option>-N</> option), in sets of 16. Each such set will also
|
||||
contain a 17th semaphore which contains a <quote>magic
|
||||
number</quote>, to detect collision with semaphore sets used by
|
||||
@ -1959,13 +1959,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<para>
|
||||
The <varname>SEMMSL</> parameter, which determines how many
|
||||
semaphores can be in a set, must be at least 17 for
|
||||
<productname>Postgres</>.
|
||||
<productname>PostgreSQL</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Various other settings related to <quote>semaphore undo</>, such as
|
||||
<varname>SEMMNU</> and <varname>SEMUME</>, are not of concern
|
||||
for <productname>Postgres</>.
|
||||
for <productname>PostgreSQL</>.
|
||||
</para>
|
||||
|
||||
|
||||
@ -2018,7 +2018,7 @@ options "SYSPTSIZE=16"
|
||||
<title>Semaphores</>
|
||||
<para>
|
||||
You may need to increase the number of semaphores. By
|
||||
default, <productname>Postgres</> allocates 34 semaphores,
|
||||
default, <productname>PostgreSQL</> allocates 34 semaphores,
|
||||
which is over half the default system total of 60.
|
||||
</para>
|
||||
</formalpara>
|
||||
@ -2167,7 +2167,7 @@ kernel.shmmax = 134217728
|
||||
<listitem>
|
||||
<para>
|
||||
At least in version 2.6, the maximum size of a shared memory
|
||||
segment is set too low for <productname>Postgres</>. The
|
||||
segment is set too low for <productname>PostgreSQL</>. The
|
||||
relevant settings can be changed in <filename>/etc/system</>,
|
||||
for example:
|
||||
<programlisting>
|
||||
@ -2235,7 +2235,7 @@ set semsys:seminfo_semmsl=32
|
||||
<para>
|
||||
Unix-like operating systems enforce various kinds of resource
|
||||
limits that might interfere with the operation of your
|
||||
<productname>Postgres</productname> server. Of importance are
|
||||
<productname>PostgreSQL</productname> server. Of importance are
|
||||
especially the limits on the number of processes per user, the
|
||||
number of open files per process, and the amount of memory
|
||||
available to a process. Each of these have a <quote>hard</quote>
|
||||
@ -2287,7 +2287,7 @@ default:\
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <productname>Postgres</productname> server uses one process
|
||||
The <productname>PostgreSQL</productname> server uses one process
|
||||
per connection so you should provide for at least as many processes
|
||||
as allowed connections, in addition to what you need for the rest
|
||||
of your system. This is usually not a problem but if you run
|
||||
@ -2465,14 +2465,14 @@ cp cert.cert <replaceable>$PGDATA</replaceable>/server.crt
|
||||
<para>
|
||||
One can use <productname>ssh</productname> to encrypt the network
|
||||
connection between clients and a
|
||||
<productname>Postgres</productname> server. Done properly, this
|
||||
<productname>PostgreSQL</productname> server. Done properly, this
|
||||
should lead to an adequately secure network connection.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
First make sure that an <application>ssh</application> server is
|
||||
running properly on the same machine as
|
||||
<productname>Postgres</productname> and that you can log in using
|
||||
<productname>PostgreSQL</productname> and that you can log in using
|
||||
<command>ssh</command> as some user. Then you can establish a secure tunnel with a
|
||||
command like this from the client machine:
|
||||
<programlisting>
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.4 2001/10/09 18:46:00 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.5 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="source">
|
||||
<title>Postgres Source Code</title>
|
||||
<title>PostgreSQL Source Code</title>
|
||||
|
||||
<sect1 id="source-format">
|
||||
<title>Formatting</title>
|
||||
@ -28,7 +28,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/sources.sgml,v 2.4 2001/10/09 18:46:00 pete
|
||||
auto-mode-alist))
|
||||
|
||||
(defun pgsql-c-mode ()
|
||||
;; sets up formatting for Postgres C code
|
||||
;; sets up formatting for PostgreSQL C code
|
||||
(interactive)
|
||||
(c-mode)
|
||||
(setq-default tab-width 4)
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/spi.sgml,v 1.19 2001/11/14 22:26:02 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/spi.sgml,v 1.20 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<Chapter id="spi">
|
||||
@ -1589,7 +1589,7 @@ Execution plan location. NULL if unsuccessful.
|
||||
protected from freeing by <Function>SPI_finish</Function> or the transaction manager.
|
||||
</para>
|
||||
<Para>
|
||||
In the current version of <ProductName>Postgres</ProductName> there is no ability to
|
||||
In the current version of <ProductName>PostgreSQL</ProductName> there is no ability to
|
||||
store prepared plans in the system
|
||||
catalog and fetch them from there for execution. This will be implemented
|
||||
in future versions.
|
||||
@ -2557,7 +2557,7 @@ Returns a newly-allocated copy of the rel name.
|
||||
<Title>Memory Management</Title>
|
||||
|
||||
<Para>
|
||||
<ProductName>Postgres</ProductName> allocates memory within memory
|
||||
<ProductName>PostgreSQL</ProductName> allocates memory within memory
|
||||
<firstterm>contexts</firstterm>, which provide a convenient method of
|
||||
managing allocations made in many different places that need to live
|
||||
for differing amounts of time. Destroying a context releases all the
|
||||
@ -3745,7 +3745,7 @@ Passed plan
|
||||
<Title>Visibility of Data Changes</Title>
|
||||
|
||||
<Para>
|
||||
<ProductName>Postgres</ProductName> data changes visibility rule: during a query execution, data
|
||||
<ProductName>PostgreSQL</ProductName> data changes visibility rule: during a query execution, data
|
||||
changes made by the query itself (via SQL-function, SPI-function, triggers)
|
||||
are invisible to the query scan. For example, in query
|
||||
<programlisting>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.18 2001/11/19 05:37:53 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/start.sgml,v 1.19 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-start">
|
||||
@ -169,7 +169,7 @@ CREATE DATABASE
|
||||
<screen>
|
||||
createdb: command not found
|
||||
</screen>
|
||||
then PostgreSQL was not installed properly. Either it was not
|
||||
then <productname>PostgreSQL</> was not installed properly. Either it was not
|
||||
installed at all or the search path was not set correctly. Try
|
||||
calling the command with an absolute path instead:
|
||||
<screen>
|
||||
@ -392,7 +392,7 @@ mydb=#
|
||||
command shell. (For more internal commands, type
|
||||
<literal>\?</literal> at the <command>psql</command> prompt.) The
|
||||
full capabilities of <command>psql</command> are documented in the
|
||||
<citetitle>Reference Manual</citetitle>. If PostgreSQL is
|
||||
<citetitle>Reference Manual</citetitle>. If <productname>PostgreSQL</> is
|
||||
installed correctly you can also type <literal>man psql</literal>
|
||||
at the operating system shell prompt to see the documentation. In
|
||||
this tutorial we will not use these features explicitly, but you
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.51 2001/11/19 09:05:01 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.52 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -174,7 +174,7 @@ UPDATE "my_table" SET "a" = 5;
|
||||
unquoted names are always folded to lower case. For example, the
|
||||
identifiers <literal>FOO</literal>, <literal>foo</literal> and
|
||||
<literal>"foo"</literal> are considered the same by
|
||||
<productname>Postgres</productname>, but <literal>"Foo"</literal>
|
||||
<productname>PostgreSQL</productname>, but <literal>"Foo"</literal>
|
||||
and <literal>"FOO"</literal> are different from these three and
|
||||
each other.
|
||||
<footnote>
|
||||
@ -201,7 +201,7 @@ UPDATE "my_table" SET "a" = 5;
|
||||
|
||||
<para>
|
||||
There are four kinds of <firstterm>implicitly typed
|
||||
constants</firstterm> in <productname>Postgres</productname>:
|
||||
constants</firstterm> in <productname>PostgreSQL</productname>:
|
||||
strings, bit strings, integers, and floating point numbers.
|
||||
Constants can also be specified with explicit types, which can
|
||||
enable more accurate representation and more efficient handling by
|
||||
@ -227,7 +227,7 @@ UPDATE "my_table" SET "a" = 5;
|
||||
is a string'</literal>. SQL allows single quotes to be embedded
|
||||
in strings by typing two adjacent single quotes (e.g.,
|
||||
<literal>'Dianne''s horse'</literal>). In
|
||||
<productname>Postgres</productname> single quotes may
|
||||
<productname>PostgreSQL</productname> single quotes may
|
||||
alternatively be escaped with a backslash (<quote>\</quote>,
|
||||
e.g., <literal>'Dianne\'s horse'</literal>).
|
||||
</para>
|
||||
@ -342,7 +342,7 @@ SELECT 'foo' 'bar';
|
||||
Floating point constants are of type <type>DOUBLE
|
||||
PRECISION</type>. <type>REAL</type> can be specified explicitly
|
||||
by using <acronym>SQL</acronym> string notation or
|
||||
<productname>Postgres</productname> type notation:
|
||||
<productname>PostgreSQL</productname> type notation:
|
||||
|
||||
<programlisting>
|
||||
REAL '1.23' -- string style
|
||||
@ -483,7 +483,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
</literallayout>
|
||||
For example, <literal>@-</literal> is an allowed operator name,
|
||||
but <literal>*-</literal> is not. This restriction allows
|
||||
<productname>Postgres</productname> to parse SQL-compliant
|
||||
<productname>PostgreSQL</productname> to parse SQL-compliant
|
||||
queries without requiring spaces between tokens.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -496,7 +496,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
For example, if you have defined a left-unary operator named <literal>@</literal>,
|
||||
you cannot write <literal>X*@Y</literal>; you must write
|
||||
<literal>X* @Y</literal> to ensure that
|
||||
<productname>Postgres</productname> reads it as two operator names
|
||||
<productname>PostgreSQL</productname> reads it as two operator names
|
||||
not one.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -641,7 +641,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
<primary>OID</primary>
|
||||
</indexterm>
|
||||
The object identifier (object ID) of a row. This is a serial number
|
||||
that is automatically added by Postgres to all table rows (unless
|
||||
that is automatically added by <productname>PostgreSQL</productname> to all table rows (unless
|
||||
the table was created WITHOUT OIDS, in which case this column is
|
||||
not present).
|
||||
</para>
|
||||
@ -734,7 +734,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
||||
a unique index on the OID column of each table for which the OID will be
|
||||
used. Never assume that OIDs are unique across tables; use the
|
||||
combination of <structfield>tableoid</> and row OID if you need a database-wide
|
||||
identifier. (Future releases of Postgres are likely to use a separate
|
||||
identifier. (Future releases of <productname>PostgreSQL</productname> are likely to use a separate
|
||||
OID counter for each table, so that <structfield>tableoid</> <emphasis>must</> be
|
||||
included to arrive at a globally unique identifier.)
|
||||
</para>
|
||||
@ -1052,7 +1052,7 @@ SELECT (5 !) - 6;
|
||||
<row>
|
||||
<entry><token>::</token></entry>
|
||||
<entry>left</entry>
|
||||
<entry><productname>Postgres</productname>-style typecast</entry>
|
||||
<entry><productname>PostgreSQL</productname>-style typecast</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<title>Triggers</title>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> has various server-side function
|
||||
<productname>PostgreSQL</productname> has various server-side function
|
||||
interfaces. Server-side functions can be written in SQL, PLPGSQL,
|
||||
TCL, or C. Trigger functions can be written in any of these
|
||||
languages except SQL. Note that STATEMENT-level trigger events are not
|
||||
@ -189,7 +189,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<note>
|
||||
<para>
|
||||
The interface described here applies for
|
||||
<productname>Postgres</productname> 7.1 and later.
|
||||
<productname>PostgreSQL</productname> 7.1 and later.
|
||||
Earlier versions passed the TriggerData pointer in a global
|
||||
variable CurrentTriggerData.
|
||||
</para>
|
||||
@ -392,7 +392,7 @@ typedef struct Trigger
|
||||
<title>Visibility of Data Changes</title>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> data changes visibility rule: during a query execution, data
|
||||
<productname>PostgreSQL</productname> data changes visibility rule: during a query execution, data
|
||||
changes made by the query itself (via SQL-function, SPI-function, triggers)
|
||||
are invisible to the query scan. For example, in query
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.12 2001/10/26 23:10:21 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.13 2001/11/21 06:09:45 thomas Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
||||
@ -339,7 +339,8 @@
|
||||
|
||||
<para>
|
||||
The <varname>WAL_SYNC_METHOD</varname> parameter determines how
|
||||
Postgres will ask the kernel to force WAL updates out to disk.
|
||||
<productname>PostgreSQL</productname> will ask the kernel to force
|
||||
WAL updates out to disk.
|
||||
All the options should be the same as far as reliability goes,
|
||||
but it's quite platform-specific which one will be the fastest.
|
||||
Note that this parameter is irrelevant if <varname>FSYNC</varname>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.14 2001/09/13 15:55:23 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.15 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xaggr">
|
||||
@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.14 2001/09/13 15:55:23 peter
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
Aggregate functions in <productname>Postgres</productname>
|
||||
Aggregate functions in <productname>PostgreSQL</productname>
|
||||
are expressed as <firstterm>state values</firstterm>
|
||||
and <firstterm>state transition functions</firstterm>.
|
||||
That is, an aggregate can be
|
||||
@ -62,7 +62,7 @@ SELECT complex_sum(a) FROM test_complex;
|
||||
</programlisting>
|
||||
|
||||
(In practice, we'd just name the aggregate <function>sum</function>, and rely on
|
||||
<productname>Postgres</productname> to figure out which kind
|
||||
<productname>PostgreSQL</productname> to figure out which kind
|
||||
of sum to apply to a complex column.)
|
||||
</para>
|
||||
|
||||
@ -77,7 +77,7 @@ SELECT complex_sum(a) FROM test_complex;
|
||||
<function>Sum</function> and some other simple aggregates like <function>Max</> and <function>Min</>,
|
||||
it's sufficient to insert the first non-null input value into
|
||||
the state variable and then start applying the transition function
|
||||
at the second non-null input value. <productname>Postgres</productname>
|
||||
at the second non-null input value. <productname>PostgreSQL</productname>
|
||||
will do that automatically if the initial condition is NULL and
|
||||
the transition function is marked <quote>strict</> (i.e., not to be called
|
||||
for NULL inputs).
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.44 2001/11/18 21:28:00 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.45 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
@ -23,7 +23,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.44 2001/11/18 21:28:00 tgl E
|
||||
Consequently, while it is possible to define a new
|
||||
function without defining a new type, the reverse is
|
||||
not true. We therefore describe how to add new functions
|
||||
to <productname>Postgres</productname> before describing
|
||||
to <productname>PostgreSQL</productname> before describing
|
||||
how to add new types.
|
||||
</para>
|
||||
|
||||
@ -575,7 +575,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
<listitem>
|
||||
<para>
|
||||
If the name starts with the string <literal>$libdir</literal>,
|
||||
that part is replaced by the PostgreSQL package library directory
|
||||
that part is replaced by the <productname>PostgreSQL</> package
|
||||
library directory
|
||||
name, which is determined at build time.<indexterm><primary>$libdir</></>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -669,7 +670,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
|
||||
<para>
|
||||
<xref linkend="xfunc-c-type-table"> gives the C type required for
|
||||
parameters in the C functions that will be loaded into Postgres.
|
||||
parameters in the C functions that will be loaded into
|
||||
<productname>PostgreSQL</>
|
||||
The <quote>Defined In</quote> column gives the header file that
|
||||
needs to be included to get the type definition. (The actual
|
||||
definition may be in a different file that is included by the
|
||||
@ -853,11 +855,11 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
</table>
|
||||
|
||||
<para>
|
||||
Internally, <productname>Postgres</productname> regards a
|
||||
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>Postgres</productname> can operate
|
||||
on it. That is, <productname>Postgres</productname> will
|
||||
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.
|
||||
Base types can have one of three internal formats:
|
||||
@ -920,7 +922,7 @@ typedef struct
|
||||
|
||||
<para>
|
||||
Only pointers to such types can be used when passing
|
||||
them in and out of <productname>Postgres</productname> functions.
|
||||
them in and out of <productname>PostgreSQL</productname> functions.
|
||||
To return a value of such a type, allocate the right amount of
|
||||
memory with <literal>palloc()</literal>, fill in the allocated memory,
|
||||
and return a pointer to it. (Alternatively, you can return an input
|
||||
@ -955,7 +957,7 @@ typedef struct {
|
||||
if it were declared the right length. (If this isn't a familiar trick to
|
||||
you, you may wish to spend some time with an introductory
|
||||
<acronym>C</acronym> programming textbook before delving deeper into
|
||||
<productname>Postgres</productname> server programming.)
|
||||
<productname>PostgreSQL</productname> server programming.)
|
||||
When manipulating
|
||||
variable-length types, we must be careful to allocate
|
||||
the correct amount of memory and set the length field correctly.
|
||||
@ -1071,7 +1073,7 @@ concat_text(text *arg1, text *arg2)
|
||||
<para>
|
||||
Supposing that the above code has been prepared in file
|
||||
<filename>funcs.c</filename> and compiled into a shared object,
|
||||
we could define the functions to <productname>Postgres</productname>
|
||||
we could define the functions to <productname>PostgreSQL</productname>
|
||||
with commands like this:
|
||||
|
||||
<programlisting>
|
||||
@ -1101,7 +1103,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
|
||||
|
||||
<para>
|
||||
Here <replaceable>PGROOT</replaceable> stands for the full path to
|
||||
the <productname>Postgres</productname> source tree. (Better style would
|
||||
the <productname>PostgreSQL</productname> source tree. (Better style would
|
||||
be to use just <literal>'funcs'</> in the <literal>AS</> clause,
|
||||
after having added <replaceable>PGROOT</replaceable><literal>/tutorial</>
|
||||
to the search path. In any case, we may omit the system-specific
|
||||
@ -1146,7 +1148,8 @@ PG_FUNCTION_INFO_V1(funcname);
|
||||
</programlisting>
|
||||
must appear in the same source file (conventionally it's written
|
||||
just before the function itself). This macro call is not needed
|
||||
for <literal>internal</>-language functions, since Postgres currently
|
||||
for <literal>internal</>-language functions, since
|
||||
<productname>PostgreSQL</> currently
|
||||
assumes all internal functions are version-1. However, it is
|
||||
<emphasis>required</emphasis> for dynamically-loaded functions.
|
||||
</para>
|
||||
@ -1307,9 +1310,9 @@ concat_text(PG_FUNCTION_ARGS)
|
||||
null fields. In addition, composite types that are
|
||||
part of an inheritance hierarchy may have different
|
||||
fields than other members of the same inheritance hierarchy.
|
||||
Therefore, <productname>Postgres</productname> provides
|
||||
Therefore, <productname>PostgreSQL</productname> provides
|
||||
a procedural interface for accessing fields of composite types
|
||||
from C. As <productname>Postgres</productname> processes
|
||||
from C. As <productname>PostgreSQL</productname> processes
|
||||
a set of rows, each row will be passed into your
|
||||
function as an opaque structure of type <literal>TUPLE</literal>.
|
||||
Suppose we want to write a function to answer the query
|
||||
@ -1363,7 +1366,7 @@ c_overpaid(PG_FUNCTION_ARGS)
|
||||
|
||||
<para>
|
||||
<function>GetAttributeByName</function> is the
|
||||
<productname>Postgres</productname> system function that
|
||||
<productname>PostgreSQL</productname> system function that
|
||||
returns attributes out of the current row. It has
|
||||
three arguments: the argument of type <type>TupleTableSlot*</type> passed into
|
||||
the function, the name of the desired attribute, and a
|
||||
@ -1374,7 +1377,7 @@ c_overpaid(PG_FUNCTION_ARGS)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following query lets <productname>Postgres</productname>
|
||||
The following query lets <productname>PostgreSQL</productname>
|
||||
know about the <function>c_overpaid</function> function:
|
||||
|
||||
<programlisting>
|
||||
@ -1403,9 +1406,9 @@ LANGUAGE C;
|
||||
have a good understanding of <acronym>C</acronym>
|
||||
(including the use of pointers and the malloc memory manager)
|
||||
before trying to write <acronym>C</acronym> functions for
|
||||
use with <productname>Postgres</productname>. While it may
|
||||
use with <productname>PostgreSQL</productname>. While it may
|
||||
be possible to load functions written in languages other
|
||||
than <acronym>C</acronym> into <productname>Postgres</productname>,
|
||||
than <acronym>C</acronym> into <productname>PostgreSQL</productname>,
|
||||
this is often difficult (when it is possible at all)
|
||||
because other languages, such as <acronym>FORTRAN</acronym>
|
||||
and <acronym>Pascal</acronym> often do not follow the same
|
||||
@ -1425,9 +1428,10 @@ LANGUAGE C;
|
||||
<listitem>
|
||||
<para>
|
||||
Use <literal>pg_config --includedir-server</literal><indexterm><primary>pg_config</></> to find
|
||||
out where the PostgreSQL server header files are installed on
|
||||
out where the <productname>PostgreSQL</> server header files are installed on
|
||||
your system (or the system that your users will be running
|
||||
on). This option is new with PostgreSQL 7.2. For PostgreSQL
|
||||
on). This option is new with <productname>PostgreSQL</> 7.2.
|
||||
For <productname>PostgreSQL</>
|
||||
7.1 you should use the option <option>--includedir</option>.
|
||||
(<command>pg_config</command> will exit with a non-zero status
|
||||
if it encounters an unknown option.) For releases prior to
|
||||
@ -1440,7 +1444,7 @@ LANGUAGE C;
|
||||
<listitem>
|
||||
<para>
|
||||
When allocating memory, use the
|
||||
<productname>Postgres</productname> routines
|
||||
<productname>PostgreSQL</productname> routines
|
||||
<function>palloc</function> and <function>pfree</function>
|
||||
instead of the corresponding <acronym>C</acronym> library
|
||||
routines <function>malloc</function> and
|
||||
@ -1465,7 +1469,7 @@ LANGUAGE C;
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Most of the internal <productname>Postgres</productname> types
|
||||
Most of the internal <productname>PostgreSQL</productname> types
|
||||
are declared in <filename>postgres.h</filename>, while the function
|
||||
manager interfaces (<symbol>PG_FUNCTION_ARGS</symbol>, etc.)
|
||||
are in <filename>fmgr.h</filename>, so you will need to
|
||||
@ -1492,7 +1496,7 @@ LANGUAGE C;
|
||||
<para>
|
||||
Compiling and linking your object code so that
|
||||
it can be dynamically loaded into
|
||||
<productname>Postgres</productname>
|
||||
<productname>PostgreSQL</productname>
|
||||
always requires special flags.
|
||||
See <xref linkend="dfunc">
|
||||
for a detailed explanation of how to do it for
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.20 2001/10/26 21:17:03 tgl Exp $
|
||||
Postgres documentation
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.21 2001/11/21 06:09:45 thomas Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
<chapter id="xindex">
|
||||
@ -17,7 +17,7 @@ Postgres documentation
|
||||
Look back at
|
||||
<xref linkend="EXTEND-CATALOGS">.
|
||||
The right half shows the catalogs that we must modify in order to tell
|
||||
<productname>Postgres</productname> how to use a user-defined type and/or
|
||||
<productname>PostgreSQL</productname> how to use a user-defined type and/or
|
||||
user-defined operators with an index (i.e., <filename>pg_am, pg_amop,
|
||||
pg_amproc, pg_operator</filename> and <filename>pg_opclass</filename>).
|
||||
Unfortunately, there is no simple command to do this. We will demonstrate
|
||||
@ -29,7 +29,7 @@ Postgres documentation
|
||||
<para>
|
||||
The <filename>pg_am</filename> table contains one row for every index
|
||||
access method. Support for the heap access method is built into
|
||||
<productname>Postgres</productname>, but every other access method is
|
||||
<productname>PostgreSQL</productname>, but every other access method is
|
||||
described in <filename>pg_am</filename>. The schema is
|
||||
|
||||
<table tocentry="1">
|
||||
@ -121,18 +121,18 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
The <filename>amstrategies</filename> column exists to standardize
|
||||
comparisons across data types. For example, <acronym>B-tree</acronym>s
|
||||
impose a strict ordering on keys, lesser to greater. Since
|
||||
<productname>Postgres</productname> allows the user to define operators,
|
||||
<productname>Postgres</productname> cannot look at the name of an operator
|
||||
<productname>PostgreSQL</productname> allows the user to define operators,
|
||||
<productname>PostgreSQL</productname> cannot look at the name of an operator
|
||||
(e.g., <literal>></> or <literal><</>) and tell what kind of comparison it is. In fact,
|
||||
some access methods don't impose any ordering at all. For example,
|
||||
<acronym>R-tree</acronym>s express a rectangle-containment relationship,
|
||||
whereas a hashed data structure expresses only bitwise similarity based
|
||||
on the value of a hash function. <productname>Postgres</productname>
|
||||
on the value of a hash function. <productname>PostgreSQL</productname>
|
||||
needs some consistent way of taking a qualification in your query,
|
||||
looking at the operator and then deciding if a usable index exists. This
|
||||
implies that <productname>Postgres</productname> needs to know, for
|
||||
implies that <productname>PostgreSQL</productname> needs to know, for
|
||||
example, that the <literal><=</> and <literal>></> operators partition a
|
||||
<acronym>B-tree</acronym>. <productname>Postgres</productname>
|
||||
<acronym>B-tree</acronym>. <productname>PostgreSQL</productname>
|
||||
uses strategies to express these relationships between
|
||||
operators and the way they can be used to scan indexes.
|
||||
</para>
|
||||
@ -208,7 +208,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
|
||||
<para>
|
||||
In order to manage diverse support routines consistently across all
|
||||
<productname>Postgres</productname> access methods,
|
||||
<productname>PostgreSQL</productname> access methods,
|
||||
<filename>pg_am</filename> includes a column called
|
||||
<filename>amsupport</filename>. This column records the number of
|
||||
support routines used by an access method. For <acronym>B-tree</acronym>s,
|
||||
@ -337,7 +337,7 @@ SELECT oid, *
|
||||
</para>
|
||||
|
||||
<para>
|
||||
We make the function known to Postgres like this:
|
||||
We make the function known to <productname>PostgreSQL</productname> like this:
|
||||
<programlisting>
|
||||
CREATE FUNCTION complex_abs_eq(complex, complex)
|
||||
RETURNS bool
|
||||
@ -362,7 +362,7 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Second, although Postgres can cope with operators having
|
||||
Second, although <productname>PostgreSQL</productname> can cope with operators having
|
||||
the same name as long as they have different input data types, C can only
|
||||
cope with one global routine having a given name, period. So we shouldn't
|
||||
name the C function something simple like <filename>abs_eq</filename>.
|
||||
@ -371,11 +371,11 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Third, we could have made the Postgres name of the function
|
||||
<filename>abs_eq</filename>, relying on Postgres to distinguish it
|
||||
by input data types from any other Postgres function of the same name.
|
||||
Third, we could have made the <productname>PostgreSQL</productname> name of the function
|
||||
<filename>abs_eq</filename>, relying on <productname>PostgreSQL</productname> to distinguish it
|
||||
by input data types from any other <productname>PostgreSQL</productname> function of the same name.
|
||||
To keep the example simple, we make the function have the same names
|
||||
at the C level and Postgres level.
|
||||
at the C level and <productname>PostgreSQL</productname> level.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -484,7 +484,7 @@ CREATE OPERATOR = (
|
||||
<filename>pg_amproc</filename> table, keyed by the operator class
|
||||
<filename>oid</filename> and the support routine number.
|
||||
First, we need to register the function in
|
||||
<productname>Postgres</productname> (recall that we put the
|
||||
<productname>PostgreSQL</productname> (recall that we put the
|
||||
<acronym>C</acronym> code that implements this routine in the bottom of
|
||||
the file in which we implemented the operator routines):
|
||||
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.15 2001/10/26 21:17:03 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.16 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="xoper">
|
||||
<Title>Extending <Acronym>SQL</Acronym>: Operators</Title>
|
||||
|
||||
<Para>
|
||||
<ProductName>Postgres</ProductName> supports left unary,
|
||||
<ProductName>PostgreSQL</ProductName> supports left unary,
|
||||
right unary and binary
|
||||
operators. Operators can be overloaded; that is,
|
||||
the same operator name can be used for different operators
|
||||
@ -87,7 +87,7 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
</note>
|
||||
|
||||
<para>
|
||||
A <ProductName>Postgres</ProductName> operator definition can include
|
||||
A <ProductName>PostgreSQL</ProductName> operator definition can include
|
||||
several optional clauses that tell the system useful things about how
|
||||
the operator behaves. These clauses should be provided whenever
|
||||
appropriate, because they can make for considerable speedups in execution
|
||||
@ -101,7 +101,7 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
|
||||
<para>
|
||||
Additional optimization clauses might be added in future versions of
|
||||
<ProductName>Postgres</ProductName>. The ones described here are all
|
||||
<ProductName>PostgreSQL</ProductName>. The ones described here are all
|
||||
the ones that release 6.5 understands.
|
||||
</para>
|
||||
|
||||
@ -121,7 +121,7 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
<para>
|
||||
The left argument type of a commuted operator is the same as the
|
||||
right argument type of its commutator, and vice versa. So the name of
|
||||
the commutator operator is all that <ProductName>Postgres</ProductName>
|
||||
the commutator operator is all that <ProductName>PostgreSQL</ProductName>
|
||||
needs to be given to look up the commutator, and that's all that need
|
||||
be provided in the COMMUTATOR clause.
|
||||
</para>
|
||||
@ -138,7 +138,7 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
<para>
|
||||
One way is to omit the COMMUTATOR clause in the first operator that
|
||||
you define, and then provide one in the second operator's definition.
|
||||
Since <ProductName>Postgres</ProductName> knows that commutative
|
||||
Since <ProductName>PostgreSQL</ProductName> knows that commutative
|
||||
operators come in pairs, when it sees the second definition it will
|
||||
automatically go back and fill in the missing COMMUTATOR clause in
|
||||
the first definition.
|
||||
@ -148,18 +148,18 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
<listitem>
|
||||
<para>
|
||||
The other, more straightforward way is just to include COMMUTATOR clauses
|
||||
in both definitions. When <ProductName>Postgres</ProductName> processes
|
||||
in both definitions. When <ProductName>PostgreSQL</ProductName> processes
|
||||
the first definition and realizes that COMMUTATOR refers to a non-existent
|
||||
operator, the system will make a dummy entry for that operator in the
|
||||
system's pg_operator table. This dummy entry will have valid data only
|
||||
for the operator name, left and right argument types, and result type,
|
||||
since that's all that <ProductName>Postgres</ProductName> can deduce
|
||||
since that's all that <ProductName>PostgreSQL</ProductName> can deduce
|
||||
at this point. The first operator's catalog entry will link to this
|
||||
dummy entry. Later, when you define the second operator, the system
|
||||
updates the dummy entry with the additional information from the second
|
||||
definition. If you try to use the dummy operator before it's been filled
|
||||
in, you'll just get an error message. (Note: this procedure did not work
|
||||
reliably in <ProductName>Postgres</ProductName> versions before 6.5,
|
||||
reliably in <ProductName>PostgreSQL</ProductName> versions before 6.5,
|
||||
but it is now the recommended way to do things.)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.15 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.16 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xplang">
|
||||
<title id="xplang-title">Procedural Languages</title>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</productname> allows users to add new
|
||||
<productname>PostgreSQL</productname> allows users to add new
|
||||
programming languages to be available for writing functions and
|
||||
procedures. These are called <firstterm>procedural
|
||||
languages</firstterm> (PL). In the case of a function or trigger
|
||||
@ -16,7 +16,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.15 2001/09/10 21:58:47 pete
|
||||
the details of the language. The handler could either do all the
|
||||
work of parsing, syntax analysis, execution, etc. itself, or it
|
||||
could serve as <quote>glue</quote> between
|
||||
<productname>Postgres</productname> and an existing implementation
|
||||
<productname>PostgreSQL</productname> and an existing implementation
|
||||
of a programming language. The handler itself is a special
|
||||
programming language function compiled into a shared object and
|
||||
loaded on demand.
|
||||
@ -26,7 +26,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.15 2001/09/10 21:58:47 pete
|
||||
Writing a handler for a new procedural language is outside the
|
||||
scope of this manual, although some information is provided in
|
||||
the CREATE LANGUAGE reference page. Several procedural languages are
|
||||
available in the standard <productname>Postgres</productname> distribution.
|
||||
available in the standard <productname>PostgreSQL</productname> distribution.
|
||||
</para>
|
||||
|
||||
<sect1 id="xplang-install">
|
||||
@ -110,7 +110,7 @@ CREATE <optional>TRUSTED</optional> <optional>PROCEDURAL</optional> LANGUAGE <re
|
||||
</procedure>
|
||||
|
||||
<para>
|
||||
In a default <productname>Postgres</productname> installation, the
|
||||
In a default <productname>PostgreSQL</productname> installation, the
|
||||
handler for the <application>PL/pgSQL</application> language is built and installed into the
|
||||
<quote>library</quote> directory. If Tcl/Tk support is configured
|
||||
in, the handlers for PL/Tcl and PL/TclU are also built and installed in
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
<para>
|
||||
As previously mentioned, there are two kinds of types
|
||||
in <productname>Postgres</productname>: base types (defined in a programming language)
|
||||
in <productname>PostgreSQL</productname>: base types (defined in a programming language)
|
||||
and composite types.
|
||||
Examples in this section up to interfacing indexes can
|
||||
be found in <filename>complex.sql</filename> and <filename>complex.c</filename>. Composite examples
|
||||
@ -127,10 +127,10 @@ CREATE TYPE complex (
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As discussed earlier, <productname>Postgres</productname> fully supports arrays of
|
||||
base types. Additionally, <productname>Postgres</productname> supports arrays of
|
||||
As discussed earlier, <productname>PostgreSQL</productname> fully supports arrays of
|
||||
base types. Additionally, <productname>PostgreSQL</productname> supports arrays of
|
||||
user-defined types as well. When you define a type,
|
||||
<productname>Postgres</productname> automatically provides support for arrays of
|
||||
<productname>PostgreSQL</productname> automatically provides support for arrays of
|
||||
that type. For historical reasons, the array type has
|
||||
the same name as the user-defined type with the
|
||||
underscore character _ prepended.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.13 2001/11/21 06:09:45 thomas Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="y2k">
|
||||
@ -26,9 +26,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
|
||||
<listitem>
|
||||
<para>
|
||||
The author of this statement, a volunteer on the
|
||||
<productname>Postgres</productname>
|
||||
<productname>PostgreSQL</productname>
|
||||
support team since November, 1996, is not aware of
|
||||
any problems in the <productname>Postgres</productname> code base related
|
||||
any problems in the <productname>PostgreSQL</productname> code base related
|
||||
to time transitions around Jan 1, 2000 (Y2K).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -38,7 +38,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
|
||||
The author of this statement is not aware of any reports of Y2K problems
|
||||
uncovered in regression testing
|
||||
or in other field use of recent or current versions
|
||||
of <productname>Postgres</productname>. We might have expected
|
||||
of <productname>PostgreSQL</productname>. We might have expected
|
||||
to hear about problems if they existed, given the installed base and
|
||||
the active participation of users on the support mailing lists.
|
||||
</para>
|
||||
@ -47,7 +47,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
|
||||
<listitem>
|
||||
<para>
|
||||
To the best of the author's knowledge, the
|
||||
assumptions Postgres makes about dates specified with a two-digit year
|
||||
assumptions <productname>PostgreSQL</productname>
|
||||
makes about dates specified with a two-digit year
|
||||
are documented in the current <citetitle>User's Guide</citetitle>
|
||||
in the chapter on data types.
|
||||
For two-digit years, the significant transition year is 1970, not 2000;
|
||||
@ -60,7 +61,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
|
||||
<para>
|
||||
Any Y2K problems in the underlying OS related to obtaining the
|
||||
<quote>current time</quote> may propagate into apparent Y2K problems in
|
||||
<productname>Postgres</productname>.
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user