Purge "Postgres" in favor of "PostgreSQL" in docs. ref/ not yet done.
<!-- 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
-->
<para>
This part provides reference information for the
<acronym>SQL</acronym> functions supported by
- <productname>Postgres</productname>.
+ <productname>PostgreSQL</productname>.
</para>
¤tDate;
<!--
-$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">
<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
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.
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>
<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.
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>
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>
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>
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,
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,
\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
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>
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)
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)
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)
<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>
<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
<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>
-<!-- $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>
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>
<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>
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
<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
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
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
</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
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>
</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
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>
<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.
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.
<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
<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
<!--
-$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">
</para>
<sect1 id="postgres-user">
- <title>The Postgres user account</title>
+ <title>The <productname>PostgreSQL</productname> user account</title>
<indexterm>
<primary>postgres user</primary>
<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
> <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>
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>
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>
> <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.
<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:
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,
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
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>
<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>
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>
<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
</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>
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>
<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
</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
<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
<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.
<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
<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>
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
<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
</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
<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>
<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>
<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>
<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>
</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
<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>
<!--
-$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>
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)
<!--
-$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">
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.
<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
<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>
<!--
-$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">
<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>
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
<!--
-$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">
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>
<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
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>
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
</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>
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>
<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>
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>
<row>
<entry><token>::</token></entry>
<entry>left</entry>
- <entry><productname>Postgres</productname>-style typecast</entry>
+ <entry><productname>PostgreSQL</productname>-style typecast</entry>
</row>
<row>
<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
<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>
<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
-<!-- $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>
<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>
<!--
-$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">
</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
</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>
<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).
<!--
-$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">
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>
<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>
<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
</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:
<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
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.
<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>
<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
</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>
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
<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
</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>
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
<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
<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
<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
<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
<!--
-$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">
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
<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">
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>
<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,
</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
</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>.
</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>
<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):
<!--
-$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
</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
<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>
<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>
<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.
<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>
<!--
-$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
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.
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">
</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
<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
</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.
<!--
-$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">
<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>
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>
<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;
<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>
OSDN Git Service
