diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml
index e4c85ed699f..fd038179741 100644
--- a/doc/src/sgml/reference.sgml
+++ b/doc/src/sgml/reference.sgml
@@ -1,5 +1,5 @@
@@ -128,7 +128,7 @@ Disable this chapter until we have more functions documented.
This part provides reference information for the
SQL functions supported by
- Postgres.
+ PostgreSQL.
¤tDate;
diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml
index 453d2c3f271..a85ff6d4028 100644
--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
@@ -1,5 +1,5 @@
@@ -829,7 +829,7 @@ ecpg changes (Michael)
A dump/restore using pg_dump
is required for those wishing to migrate data from any
- previous release of Postgres.
+ previous release of PostgreSQL.
For those upgrading from 6.5.*, you may instead use
pg_upgrade to upgrade to this
release; however, a full dump/reload installation is always the
@@ -848,7 +848,7 @@ ecpg changes (Michael)
SQL92-defined types timestamp and
interval. Although there has been some effort to
ease the transition by allowing
- Postgres to recognize
+ PostgreSQL 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 Programmer's Guide has a
description of query processing, also from Stefan, and details
- on obtaining the Postgres source
+ on obtaining the PostgreSQL source
tree via anonymous CVS and
CVSup.
@@ -1569,7 +1569,7 @@ Add Win1250 (Czech) support (Pavel Behal)
A dump/restore using pg_dump
is required for those wishing to migrate data from any
- previous release of Postgres.
+ previous release of PostgreSQL.
pg_upgrade can not
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 SELECT FOR UPDATE or
an appropriate LOCK TABLE statement. This should be
taken into account when porting applications from previous releases of
- Postgres and other environments.
+ PostgreSQL and other environments.
@@ -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 Postgres.
+the type extensibility features of PostgreSQL.
There is a new chapter in the User's Guide
which covers this topic.
@@ -2029,7 +2029,7 @@ been.
A dump/restore using pg_dump
or pg_dumpall
is required for those wishing to migrate data from any
-previous release of Postgres.
+previous release of PostgreSQL.
@@ -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
make distclean, make, and 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 Postgres libraries.
+You should re-link any custom applications that use PostgreSQL libraries.
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
make distclean, make, and 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 Postgres libraries.
+You should re-link any custom applications that use PostgreSQL libraries.
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 /pgsql/interfaces for some new
- ways to talk to Postgres.
+ ways to talk to PostgreSQL.
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 pg_dump
or pg_dumpall
is required for those wishing to migrate data from any
- previous release of Postgres.
+ previous release of PostgreSQL.
@@ -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 Postgres Procedural Language (PL) backend interface(Jan)
+New PostgreSQL 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 Postgres reserved words as column identifiers(Thomas)
+Allow more SQL92 and/or PostgreSQL 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)
A dump/restore is required for those wishing to migrate data from
-previous releases of Postgres.
+previous releases of PostgreSQL.
@@ -3071,19 +3071,19 @@ pg_dumpall now returns proper status, portability fix(Bruce)
The regression tests have been adapted and extensively modified for the
- 6.1 release of Postgres.
+ 6.1 release of PostgreSQL.
Three new data types (datetime, timespan, and circle) have been added to
- the native set of Postgres types. Points, boxes, paths, and polygons
+ the native set of PostgreSQL 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.
- Postgres 6.1 introduces a new, alternate
+ PostgreSQL 6.1 introduces a new, alternate
optimizer which uses genetic
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
A dump/restore is required for those wishing to migrate data from
-previous releases of Postgres.
+previous releases of PostgreSQL.
diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 6036a075c40..01a536e800d 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1,4 +1,4 @@
-
+
The Rule System
@@ -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 Postgres
+ the theoretical foundations of the PostgreSQL
rule system can be found in
.
@@ -26,7 +26,7 @@
Some other database systems define active database rules. These
are usually stored procedures and triggers and are implemented
- in Postgres as functions and triggers.
+ in PostgreSQL as functions and triggers.
@@ -64,7 +64,7 @@
Now what is a query tree? It is an internal representation of an
SQL statement where the single parts that built
it are stored separately. These query trees are visible when starting
- the Postgres backend with debug level 4
+ the PostgreSQL backend with debug level 4
and typing queries into the interactive backend interface. The rule
actions in the pg_rewrite system catalog are
also stored as query trees. They are not formatted like the debug
@@ -268,10 +268,10 @@
rulesand views
-Implementation of Views in <ProductName>Postgres</ProductName>
+Implementation of Views in <ProductName>PostgreSQL</ProductName>
- Views in Postgres are implemented
+ Views in PostgreSQL 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 Postgres
+ the information about a view in the PostgreSQL
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;
- Now another detail of Postgres enters the
+ Now another detail of PostgreSQL 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 @@
-The Power of Views in <ProductName>Postgres</ProductName>
+The Power of Views in <ProductName>PostgreSQL</ProductName>
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 Postgres
+ the rule system as implemented in PostgreSQL
ensures, that this is all information available about the query
up to now.
@@ -1604,7 +1604,7 @@ Merge Join
- A final demonstration of the Postgres
+ A final demonstration of the PostgreSQL
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 Postgres,
+ To make it a little harder for PostgreSQL,
we don't delete it directly. Instead we create one more view
@@ -1708,7 +1708,7 @@ Merge Join
Rules and Permissions
- Due to rewriting of queries by the Postgres
+ Due to rewriting of queries by the PostgreSQL
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 Postgres rule system changes the
+ The PostgreSQL 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
Many things that can be done using triggers can also be
- implemented using the Postgres
+ implemented using the PostgreSQL
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
Another situation is cases on UPDATE where it depends on the
change of an attribute if an action should be performed or
- not. In Postgres version 6.4, the
+ not. In PostgreSQL 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
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 81141607dfc..c694cfc7555 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
@@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
- The Postgres user account
+ The <productname>PostgreSQL</productname> user accountpostgres user
@@ -19,7 +19,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.96 2001/11/20 04:27:49 tgl
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 PostgreSQL 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 nobody 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
> initdb -D /usr/local/pgsql/data
Note that you must execute this command while being logged in to
- the Postgres user account, which is described in the previous
+ the PostgreSQL user account, which is described in the previous
section.
@@ -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:
+ PostgreSQL user account. Here is how this might work:
root# mkdir /usr/local/pgsql/data
root# chown postgres /usr/local/pgsql/data
@@ -115,7 +115,7 @@ postgres> initdb -D /usr/local/pgsql/data
Because the data directory contains all the data stored in the
database it is essential that it be well secured from unauthorized
access. initdb therefore revokes access
- permissions from everyone but the Postgres user account.
+ permissions from everyone but the PostgreSQL user account.
@@ -159,7 +159,7 @@ NOTICE: Initializing database with en_US collation order.
> postmaster -D /usr/local/pgsql/data
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 PostgreSQL user account. Without
a , the server will try to use the data
directory in the environment variable PGDATA; if
neither of these works it will fail.
@@ -221,7 +221,7 @@ pg_ctl start -l logfile
/etc/rc.local or
/etc/rc.d/rc.local which is almost certainly
no bad place to put such a command. Whatever you do, the server
- must be run by the Postgres user account
+ must be run by the PostgreSQL user account
and not by root or any other user. Therefore
you probably always want to form your command lines along the lines
of su -c '...' postgres, for example:
@@ -347,7 +347,7 @@ IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argum
FATAL 1: ShmemCreate: cannot create region
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 PostgreSQL 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 not 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
- Postgres wants to create. As above,
+ PostgreSQL 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
( 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
- Postgres data files). This is
+ PostgreSQL data files). This is
measured in disk pages, which are normally 8 kB apiece.
@@ -756,7 +756,7 @@ env PGOPTIONS='-c geqo=off' psql
The KSQO algorithm used to be absolutely essential for queries
with many OR'ed AND clauses, but in
- Postgres 7.0 and later the standard
+ PostgreSQL 7.0 and later the standard
planner handles these queries fairly successfully. Hence the
default is OFF.
@@ -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 USE_ASSERT_CHECKING
- must be defined when Postgres is built (see the configure option
+ must be defined when PostgreSQL is built (see the configure option
--enable-cassert). Note that
- DEBUG_ASSERTIONS defaults to ON if Postgres
+ DEBUG_ASSERTIONS defaults to ON if PostgreSQL
has been built this way.
@@ -957,7 +957,7 @@ env PGOPTIONS='-c geqo=off' psql
SYSLOG (integer)
- Postgres allows the use of
+ PostgreSQL allows the use of
syslog for logging. If this option
is set to 1, messages go both to syslog and the standard
output. A setting of 2 sends output only to syslog. (Some
@@ -967,7 +967,7 @@ env PGOPTIONS='-c geqo=off' psql
To use syslog, the build of
- Postgres must be configured with
+ PostgreSQL must be configured with
the option.
@@ -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 $libdir, the
- compiled-in PostgreSQL package library directory, which is where the
- modules provided by the PostgreSQL distribution are installed,
+ compiled-in PostgreSQL package library directory, which is where the
+ modules provided by the PostgreSQL distribution are installed,
is substituted. (Use pg_config --pkglibdir
to print the name of this directory.) An example value:
@@ -1157,7 +1157,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
FSYNC (boolean)
- If this option is on, the Postgres backend
+ If this option is on, the PostgreSQL backend
will use the 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'
- However, this operation slows down Postgres,
+ However, this operation slows down PostgreSQL,
because at all those points it has
to block and wait for the operating system to flush the
buffers. Without fsync, the operating system is
@@ -1181,7 +1181,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
This option is the subject of an eternal debate in the
- Postgres user and developer communities. Some
+ 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'
It should be noted that the performance penalty from doing
- fsyncs is considerably less in Postgres version
+ fsyncs is considerably less in 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'
Managing Kernel Resources
- A large Postgres installation can quickly hit
+ A large 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
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'
Shared memory and semaphores are collectively referred to as
System V IPC (together with message queues, which are
- not relevant for Postgres). Almost all modern
+ not relevant for 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 QNX and BeOS ports,
- Postgres provides its own replacement
+ PostgreSQL provides its own replacement
implementation of these facilities.)
@@ -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
Illegal system call error upon postmaster start. In
that case there's nothing left to do but to reconfigure your
- kernel -- Postgres won't work without them.
+ kernel -- PostgreSQL won't work without them.
- When Postgres exceeds one of the various hard
+ When PostgreSQL exceeds one of the various hard
limits of the 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'
Less likely to cause problems is the minimum size for shared
memory segments (SHMMIN), which should be at most
- somewhere around 256 kB for Postgres (it is
+ somewhere around 256 kB for PostgreSQL (it is
usually just 1). The maximum number of segments system-wide
(SHMMNI) or per-process (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'
- Postgres uses one semaphore per allowed connection
+ PostgreSQL uses one semaphore per allowed connection
(
- In the current version of Postgres there is no ability to
+ In the current version of PostgreSQL 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.
Memory Management
-Postgres allocates memory within memory
+PostgreSQL allocates memory within memory
contexts, 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
Visibility of Data Changes
-Postgres data changes visibility rule: during a query execution, data
+PostgreSQL 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
diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index 2e6eddefb6f..bda58c4ef1f 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -1,5 +1,5 @@
@@ -169,7 +169,7 @@ CREATE DATABASE
createdb: command not found
- then PostgreSQL was not installed properly. Either it was not
+ then 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:
@@ -392,7 +392,7 @@ mydb=#
command shell. (For more internal commands, type
\? at the psql prompt.) The
full capabilities of psql are documented in the
- Reference Manual. If PostgreSQL is
+ Reference Manual. If PostgreSQL is
installed correctly you can also type man psql
at the operating system shell prompt to see the documentation. In
this tutorial we will not use these features explicitly, but you
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index c3e1ae59eae..fa221682e4c 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -1,5 +1,5 @@
@@ -174,7 +174,7 @@ UPDATE "my_table" SET "a" = 5;
unquoted names are always folded to lower case. For example, the
identifiers FOO, foo and
"foo" are considered the same by
- Postgres, but "Foo"
+ PostgreSQL, but "Foo"
and "FOO" are different from these three and
each other.
@@ -201,7 +201,7 @@ UPDATE "my_table" SET "a" = 5;
There are four kinds of implicitly typed
- constants in Postgres:
+ constants in PostgreSQL:
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'. SQL allows single quotes to be embedded
in strings by typing two adjacent single quotes (e.g.,
'Dianne''s horse'). In
- Postgres single quotes may
+ PostgreSQL single quotes may
alternatively be escaped with a backslash (\,
e.g., 'Dianne\'s horse').
@@ -342,7 +342,7 @@ SELECT 'foo' 'bar';
Floating point constants are of type DOUBLE
PRECISION. REAL can be specified explicitly
by using SQL string notation or
- Postgres type notation:
+ PostgreSQL type notation:
REAL '1.23' -- string style
@@ -483,7 +483,7 @@ CAST ( 'string' AS type )
For example, @- is an allowed operator name,
but *- is not. This restriction allows
- Postgres to parse SQL-compliant
+ PostgreSQL to parse SQL-compliant
queries without requiring spaces between tokens.
@@ -496,7 +496,7 @@ CAST ( 'string' AS type )
For example, if you have defined a left-unary operator named @,
you cannot write X*@Y; you must write
X* @Y to ensure that
- Postgres reads it as two operator names
+ PostgreSQL reads it as two operator names
not one.
@@ -641,7 +641,7 @@ CAST ( 'string' AS type )
OID
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 PostgreSQL to all table rows (unless
the table was created WITHOUT OIDS, in which case this column is
not present).
@@ -734,7 +734,7 @@ CAST ( 'string' AS type )
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 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 PostgreSQL are likely to use a separate
OID counter for each table, so that tableoid must be
included to arrive at a globally unique identifier.)
@@ -1052,7 +1052,7 @@ SELECT (5 !) - 6;
::left
- Postgres-style typecast
+ PostgreSQL-style typecast
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml
index 2bca167378d..540ef0f71b3 100644
--- a/doc/src/sgml/trigger.sgml
+++ b/doc/src/sgml/trigger.sgml
@@ -2,7 +2,7 @@
Triggers
- Postgres has various server-side function
+ PostgreSQL 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 trigger [ BEFORE | AFTER ] [ INSERT |
The interface described here applies for
- Postgres 7.1 and later.
+ PostgreSQL 7.1 and later.
Earlier versions passed the TriggerData pointer in a global
variable CurrentTriggerData.
@@ -392,7 +392,7 @@ typedef struct Trigger
Visibility of Data Changes
- Postgres data changes visibility rule: during a query execution, data
+ PostgreSQL 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
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 4733786f95c..2b650e71d26 100644
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -1,4 +1,4 @@
-
+
Write-Ahead Logging (<acronym>WAL</acronym>)
@@ -339,7 +339,8 @@
The WAL_SYNC_METHOD parameter determines how
- Postgres will ask the kernel to force WAL updates out to disk.
+ PostgreSQL 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 FSYNC
diff --git a/doc/src/sgml/xaggr.sgml b/doc/src/sgml/xaggr.sgml
index d3e6795eb83..c73a0e0d6a7 100644
--- a/doc/src/sgml/xaggr.sgml
+++ b/doc/src/sgml/xaggr.sgml
@@ -1,5 +1,5 @@
@@ -11,7 +11,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.14 2001/09/13 15:55:23 peter
- Aggregate functions in Postgres
+ Aggregate functions in PostgreSQL
are expressed as state values
and state transition functions.
That is, an aggregate can be
@@ -62,7 +62,7 @@ SELECT complex_sum(a) FROM test_complex;
(In practice, we'd just name the aggregate sum, and rely on
- Postgres to figure out which kind
+ PostgreSQL to figure out which kind
of sum to apply to a complex column.)
@@ -77,7 +77,7 @@ SELECT complex_sum(a) FROM test_complex;
Sum and some other simple aggregates like Max and 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. Postgres
+ at the second non-null input value. PostgreSQL
will do that automatically if the initial condition is NULL and
the transition function is marked strict (i.e., not to be called
for NULL inputs).
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 72500380425..1b3c86d3f03 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -1,5 +1,5 @@
@@ -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 Postgres before describing
+ to PostgreSQL before describing
how to add new types.
@@ -575,7 +575,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
If the name starts with the string $libdir,
- that part is replaced by the PostgreSQL package library directory
+ that part is replaced by the PostgreSQL package
+ library directory
name, which is determined at build time.$libdir
@@ -669,7 +670,8 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
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
+ PostgreSQL
The Defined In 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
- Internally, Postgres regards a
+ Internally, PostgreSQL regards a
base type as a blob of memory. The user-defined
functions that you define over a type in turn define the
- way that Postgres can operate
- on it. That is, Postgres will
+ way that PostgreSQL can operate
+ on it. That is, PostgreSQL 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
Only pointers to such types can be used when passing
- them in and out of Postgres functions.
+ them in and out of PostgreSQL functions.
To return a value of such a type, allocate the right amount of
memory with palloc(), 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
C programming textbook before delving deeper into
- Postgres server programming.)
+ PostgreSQL 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)
Supposing that the above code has been prepared in file
funcs.c and compiled into a shared object,
- we could define the functions to Postgres
+ we could define the functions to PostgreSQL
with commands like this:
@@ -1101,7 +1103,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
Here PGROOT stands for the full path to
- the Postgres source tree. (Better style would
+ the PostgreSQL source tree. (Better style would
be to use just 'funcs' in the AS clause,
after having added PGROOT/tutorial
to the search path. In any case, we may omit the system-specific
@@ -1146,7 +1148,8 @@ PG_FUNCTION_INFO_V1(funcname);
must appear in the same source file (conventionally it's written
just before the function itself). This macro call is not needed
- for internal-language functions, since Postgres currently
+ for internal-language functions, since
+ PostgreSQL currently
assumes all internal functions are version-1. However, it is
required for dynamically-loaded functions.
@@ -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, Postgres provides
+ Therefore, PostgreSQL provides
a procedural interface for accessing fields of composite types
- from C. As Postgres processes
+ from C. As PostgreSQL processes
a set of rows, each row will be passed into your
function as an opaque structure of type TUPLE.
Suppose we want to write a function to answer the query
@@ -1363,7 +1366,7 @@ c_overpaid(PG_FUNCTION_ARGS)
GetAttributeByName is the
- Postgres system function that
+ PostgreSQL system function that
returns attributes out of the current row. It has
three arguments: the argument of type TupleTableSlot* passed into
the function, the name of the desired attribute, and a
@@ -1374,7 +1377,7 @@ c_overpaid(PG_FUNCTION_ARGS)
- The following query lets Postgres
+ The following query lets PostgreSQL
know about the c_overpaid function:
@@ -1403,9 +1406,9 @@ LANGUAGE C;
have a good understanding of C
(including the use of pointers and the malloc memory manager)
before trying to write C functions for
- use with Postgres. While it may
+ use with PostgreSQL. While it may
be possible to load functions written in languages other
- than C into Postgres,
+ than C into PostgreSQL,
this is often difficult (when it is possible at all)
because other languages, such as FORTRAN
and Pascal often do not follow the same
@@ -1425,9 +1428,10 @@ LANGUAGE C;
Use pg_config --includedir-serverpg_config to find
- out where the PostgreSQL server header files are installed on
+ out where the 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 PostgreSQL 7.2.
+ For PostgreSQL
7.1 you should use the option .
(pg_config will exit with a non-zero status
if it encounters an unknown option.) For releases prior to
@@ -1440,7 +1444,7 @@ LANGUAGE C;
When allocating memory, use the
- Postgres routines
+ PostgreSQL routines
palloc and pfree
instead of the corresponding C library
routines malloc and
@@ -1465,7 +1469,7 @@ LANGUAGE C;
- Most of the internal Postgres types
+ Most of the internal PostgreSQL types
are declared in postgres.h, while the function
manager interfaces (PG_FUNCTION_ARGS, etc.)
are in fmgr.h, so you will need to
@@ -1492,7 +1496,7 @@ LANGUAGE C;
Compiling and linking your object code so that
it can be dynamically loaded into
- Postgres
+ PostgreSQL
always requires special flags.
See
for a detailed explanation of how to do it for
diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml
index 66b39eb0bf2..453f86ceae1 100644
--- a/doc/src/sgml/xindex.sgml
+++ b/doc/src/sgml/xindex.sgml
@@ -1,6 +1,6 @@
@@ -17,7 +17,7 @@ Postgres documentation
Look back at
.
The right half shows the catalogs that we must modify in order to tell
- Postgres how to use a user-defined type and/or
+ PostgreSQL how to use a user-defined type and/or
user-defined operators with an index (i.e., pg_am, pg_amop,
pg_amproc, pg_operator and pg_opclass).
Unfortunately, there is no simple command to do this. We will demonstrate
@@ -29,7 +29,7 @@ Postgres documentation
The pg_am table contains one row for every index
access method. Support for the heap access method is built into
- Postgres, but every other access method is
+ PostgreSQL, but every other access method is
described in pg_am. The schema is
@@ -121,18 +121,18 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
The amstrategies column exists to standardize
comparisons across data types. For example, B-trees
impose a strict ordering on keys, lesser to greater. Since
- Postgres allows the user to define operators,
- Postgres cannot look at the name of an operator
+ PostgreSQL allows the user to define operators,
+ PostgreSQL cannot look at the name of an operator
(e.g., > or <) and tell what kind of comparison it is. In fact,
some access methods don't impose any ordering at all. For example,
R-trees express a rectangle-containment relationship,
whereas a hashed data structure expresses only bitwise similarity based
- on the value of a hash function. Postgres
+ on the value of a hash function. PostgreSQL
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 Postgres needs to know, for
+ implies that PostgreSQL needs to know, for
example, that the <= and > operators partition a
- B-tree. Postgres
+ B-tree. PostgreSQL
uses strategies to express these relationships between
operators and the way they can be used to scan indexes.
@@ -208,7 +208,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
In order to manage diverse support routines consistently across all
- Postgres access methods,
+ PostgreSQL access methods,
pg_am includes a column called
amsupport. This column records the number of
support routines used by an access method. For B-trees,
@@ -337,7 +337,7 @@ SELECT oid, *
- We make the function known to Postgres like this:
+ We make the function known to PostgreSQL like this:
CREATE FUNCTION complex_abs_eq(complex, complex)
RETURNS bool
@@ -362,7 +362,7 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
- Second, although Postgres can cope with operators having
+ Second, although PostgreSQL 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 abs_eq.
@@ -371,11 +371,11 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
- Third, we could have made the Postgres name of the function
- abs_eq, 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 PostgreSQL name of the function
+ abs_eq, relying on PostgreSQL to distinguish it
+ by input data types from any other PostgreSQL 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 PostgreSQL level.
@@ -484,7 +484,7 @@ CREATE OPERATOR = (
pg_amproc table, keyed by the operator class
oid and the support routine number.
First, we need to register the function in
- Postgres (recall that we put the
+ PostgreSQL (recall that we put the
C code that implements this routine in the bottom of
the file in which we implemented the operator routines):
diff --git a/doc/src/sgml/xoper.sgml b/doc/src/sgml/xoper.sgml
index e2358dfd635..673c7702b1b 100644
--- a/doc/src/sgml/xoper.sgml
+++ b/doc/src/sgml/xoper.sgml
@@ -1,12 +1,12 @@
Extending <Acronym>SQL</Acronym>: Operators
- Postgres supports left unary,
+ PostgreSQL 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;
- A Postgres operator definition can include
+ A PostgreSQL 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;
Additional optimization clauses might be added in future versions of
- Postgres. The ones described here are all
+ PostgreSQL. The ones described here are all
the ones that release 6.5 understands.
@@ -121,7 +121,7 @@ SELECT (a + b) AS c FROM test_complex;
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 Postgres
+ the commutator operator is all that PostgreSQL
needs to be given to look up the commutator, and that's all that need
be provided in the COMMUTATOR clause.
@@ -138,7 +138,7 @@ SELECT (a + b) AS c FROM test_complex;
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 Postgres knows that commutative
+ Since PostgreSQL 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;
The other, more straightforward way is just to include COMMUTATOR clauses
- in both definitions. When Postgres processes
+ in both definitions. When PostgreSQL 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 Postgres can deduce
+ since that's all that PostgreSQL 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 Postgres versions before 6.5,
+ reliably in PostgreSQL versions before 6.5,
but it is now the recommended way to do things.)
diff --git a/doc/src/sgml/xplang.sgml b/doc/src/sgml/xplang.sgml
index bcb7dd01809..ce8c0d0ac79 100644
--- a/doc/src/sgml/xplang.sgml
+++ b/doc/src/sgml/xplang.sgml
@@ -1,12 +1,12 @@
Procedural Languages
- Postgres allows users to add new
+ PostgreSQL allows users to add new
programming languages to be available for writing functions and
procedures. These are called procedural
languages (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 glue between
- Postgres and an existing implementation
+ PostgreSQL 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 Postgres distribution.
+ available in the standard PostgreSQL distribution.
@@ -110,7 +110,7 @@ CREATE TRUSTEDPROCEDURAL LANGUAGE
- In a default Postgres installation, the
+ In a default PostgreSQL installation, the
handler for the PL/pgSQL language is built and installed into the
library directory. If Tcl/Tk support is configured
in, the handlers for PL/Tcl and PL/TclU are also built and installed in
diff --git a/doc/src/sgml/xtypes.sgml b/doc/src/sgml/xtypes.sgml
index f4a8c4c4a99..3ab3dd7e790 100644
--- a/doc/src/sgml/xtypes.sgml
+++ b/doc/src/sgml/xtypes.sgml
@@ -8,7 +8,7 @@
As previously mentioned, there are two kinds of types
- in Postgres: base types (defined in a programming language)
+ in PostgreSQL: base types (defined in a programming language)
and composite types.
Examples in this section up to interfacing indexes can
be found in complex.sql and complex.c. Composite examples
@@ -127,10 +127,10 @@ CREATE TYPE complex (
- As discussed earlier, Postgres fully supports arrays of
- base types. Additionally, Postgres supports arrays of
+ As discussed earlier, PostgreSQL fully supports arrays of
+ base types. Additionally, PostgreSQL supports arrays of
user-defined types as well. When you define a type,
- Postgres automatically provides support for arrays of
+ PostgreSQL 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.
diff --git a/doc/src/sgml/y2k.sgml b/doc/src/sgml/y2k.sgml
index 6b6e1f8725c..a41f1ad6aa1 100644
--- a/doc/src/sgml/y2k.sgml
+++ b/doc/src/sgml/y2k.sgml
@@ -1,5 +1,5 @@
@@ -26,9 +26,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
The author of this statement, a volunteer on the
- Postgres
+ PostgreSQL
support team since November, 1996, is not aware of
- any problems in the Postgres code base related
+ any problems in the PostgreSQL code base related
to time transitions around Jan 1, 2000 (Y2K).
@@ -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 Postgres. We might have expected
+ of PostgreSQL. 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.
@@ -47,7 +47,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.12 2001/11/14 20:40:33 m
To the best of the author's knowledge, the
- assumptions Postgres makes about dates specified with a two-digit year
+ assumptions PostgreSQL
+ makes about dates specified with a two-digit year
are documented in the current User's Guide
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
Any Y2K problems in the underlying OS related to obtaining the
current time may propagate into apparent Y2K problems in
- Postgres.
+ PostgreSQL.