Skip to content

P
Postgres FD Implementation
Commit 6c402eaf authored by Thomas G. Lockhart's avatar Thomas G. Lockhart
Browse files
Options

Deprecate 'current' date/time constant. 

Purge "Postgres" in favor of "PostgreSQL" in docs. ref/ not yet done.
parent 90e757c1
Expand all Show whitespace changes
Inline Side-by-side
Showing with 174 additions and 168 deletions
doc/src/sgml/reference.sgml
View file @ 6c402eaf
<!-- 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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!-- $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
View file @ 6c402eaf
This diff is collapsed.
doc/src/sgml/sources.sgml
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
......@@ -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
View file @ 6c402eaf
<!-- $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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
<!--
$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
View file @ 6c402eaf
......@@ -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
View file @ 6c402eaf
<!--
$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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment