Deprecate 'current' date/time constant.

Purge "Postgres" in favor of "PostgreSQL" in docs. ref/ not yet done.

doc/src/sgml/reference.sgml

 <!-- 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>
 
    &currentDate;

doc/src/sgml/release.sgml

 <!--
-$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>

doc/src/sgml/rules.sgml

-<!-- $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

doc/src/sgml/runtime.sgml

 <!--
-$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
 &gt; <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&gt; <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.
 &gt; <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>

doc/src/sgml/sources.sgml

 <!--
-$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)

doc/src/sgml/spi.sgml

 <!--
-$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>

doc/src/sgml/start.sgml

 <!--
-$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

doc/src/sgml/syntax.sgml

 <!--
-$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>

doc/src/sgml/trigger.sgml

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

doc/src/sgml/wal.sgml

-<!-- $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>

doc/src/sgml/xaggr.sgml

 <!--
-$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).

doc/src/sgml/xfunc.sgml

 <!--
-$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

doc/src/sgml/xindex.sgml

 <!--
-$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>&gt;</> or <literal>&lt;</>) 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>&lt;=</>  and  <literal>&gt;</> 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):
 

doc/src/sgml/xoper.sgml

 <!--
-$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>

doc/src/sgml/xplang.sgml

 <!--
-$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

doc/src/sgml/xtypes.sgml

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

doc/src/sgml/y2k.sgml

 <!--
-$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>