Replace incorrect uses of 'which' with 'that'. (so-called "wicked which")
This commit is contained in:
parent
04b31609b6
commit
1b555ce791
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.17 2000/12/18 23:39:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.18 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced">
|
||||
@ -23,7 +23,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/advanced.sgml,v 1.17 2000/12/18 23:39:37 tg
|
||||
|
||||
<para>
|
||||
Let's create two classes. The capitals class contains
|
||||
state capitals which are also cities. Naturally, the
|
||||
state capitals that are also cities. Naturally, the
|
||||
capitals class should inherit from cities.
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.11 2000/12/21 22:55:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.12 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="overview">
|
||||
@ -357,7 +357,7 @@ XXX merge in the figures later... - thomas 1999-01-29
|
||||
the parser as input and steps recursively through it. If
|
||||
a <literal>SelectStmt</literal> node is found, it is transformed
|
||||
to a <literal>Query</literal>
|
||||
node which will be the top most node of the new data structure. Figure
|
||||
node that will be the top most node of the new data structure. Figure
|
||||
\ref{transformed} shows the transformed data structure (the part
|
||||
for the transformed <firstterm>where clause</firstterm> is given in figure
|
||||
\ref{transformed_where} because there was not enough space to show all
|
||||
@ -371,7 +371,7 @@ XXX merge in the figures later... - thomas 1999-01-29
|
||||
created containing the relation name, the <firstterm>alias name</firstterm> and
|
||||
the <firstterm>relation id</firstterm>. From now on the relation ids are used to
|
||||
refer to the <firstterm>relations</firstterm> given in the query. All <abbrev>RTE</abbrev> nodes
|
||||
are collected in the <firstterm>range table entry list</firstterm> which is connected
|
||||
are collected in the <firstterm>range table entry list</firstterm> that is connected
|
||||
to the field <literal>rtable</literal> of the <literal>Query</literal> node. If a name of a
|
||||
relation that is not known to the system is detected in the query an
|
||||
error will be returned and the query processing will be aborted.
|
||||
@ -668,7 +668,7 @@ current context are performed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The top node of the plan is a <literal>MergeJoin</literal> node which has two
|
||||
The top node of the plan is a <literal>MergeJoin</literal> node that has two
|
||||
successors, one attached to the field <literal>lefttree</literal> and the second
|
||||
attached to the field <literal>righttree</literal>. Each of the subnodes represents
|
||||
one relation of the join. As mentioned above a merge sort
|
||||
@ -861,7 +861,7 @@ the {\it aggregate function} used in the query.
|
||||
|
||||
A check is made that every attribute grouped for appears only without
|
||||
an {\it aggregate function} in the {\it targetlist} and that every
|
||||
attribute which appears without an {\it aggregate function} in the
|
||||
attribute that appears without an {\it aggregate function} in the
|
||||
{\it targetlist} is grouped for.
|
||||
%
|
||||
|
||||
@ -1050,7 +1050,7 @@ the {\it parser} transform the {\it operator tree} attached to the field
|
||||
transformation of the {\it operator tree} for the {\it where clause}. This
|
||||
is possible because both trees are built up by the same grammar rules
|
||||
of the {\it parser} and are therefore compatible. Additional checks
|
||||
which make sure that the {\it having clause} involves at least one
|
||||
that make sure that the {\it having clause} involves at least one
|
||||
{\it aggregate function} etc. are performed at a later point in time
|
||||
in the {\it planner/optimizer} stage. \\
|
||||
\\
|
||||
@ -1061,7 +1061,7 @@ parts of the affected code are presented instead of the whole
|
||||
functions. Every added source line will be marked by a {\tt '+'} at the
|
||||
beginning of the line and every changed source line will be marked by
|
||||
a {\tt '!'} throughout the following code listings. Whenever a part of
|
||||
the code which is not relevant at the moment is skipped, three
|
||||
the code that is not relevant at the moment is skipped, three
|
||||
vertical dots are inserted instead.
|
||||
%
|
||||
\pagebreak
|
||||
@ -1961,7 +1961,7 @@ node.
|
||||
|
||||
Unfortunately this is not the only thing to do. Remember from section
|
||||
\ref{aggregates} {\it How Aggregate Functions are Implemented} that
|
||||
the {\it targetlist} is searched for {\it aggregate functions} which
|
||||
the {\it targetlist} is searched for {\it aggregate functions} that
|
||||
are appended to a list that will be attached to the field {\tt aggs}
|
||||
of the {\tt AGG} node. This was sufficient as long as {\it aggregate
|
||||
functions} have only been allowed to appear within the {\it
|
||||
@ -3158,7 +3158,7 @@ operators).
|
||||
%
|
||||
\end{itemize}
|
||||
%
|
||||
Here is a part of the grammar which is responsible for {\tt select}
|
||||
Here is a part of the grammar that is responsible for {\tt select}
|
||||
statements having the code building up the data structures inserted:
|
||||
%
|
||||
\pagebreak
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/bki.sgml,v 1.4 2000/09/29 20:21:33 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/bki.sgml,v 1.5 2000/12/22 18:57:49 petere Exp $
|
||||
|
||||
Transcribed from the original bki.man.5 documentation
|
||||
- Thomas Lockhart 1998-08-03
|
||||
@ -53,7 +53,7 @@ and the <acronym>SQL</acronym> command <command>CREATE DATABASE</command>.
|
||||
|
||||
<para>
|
||||
Commands are composed of a command name followed by space separated
|
||||
arguments. Arguments to a command which begin with a "$" are
|
||||
arguments. Arguments to a command that begin with a "$" are
|
||||
treated specially. If "$$" are the first two characters, then
|
||||
the first "$" is ignored and the argument is then processed
|
||||
normally. If the "$" is followed by space, then it is treated
|
||||
|
@ -1,6 +1,6 @@
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.12 2000/12/11 18:26:37 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.13 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="catalogs">
|
||||
@ -492,7 +492,7 @@
|
||||
stored in the attribute is the OID of a tuple in the
|
||||
<structname>pg_proc</structname> catalog. The
|
||||
<structname>pg_proc</structname> tuple contains the query
|
||||
string which defines this set - i.e., the query to run to get
|
||||
string that defines this set - i.e., the query to run to get
|
||||
the set. So the <structfield>atttypid</structfield> (see
|
||||
above) refers to the type returned by this query, but the
|
||||
actual length of this attribute is the length (size) of an
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.11 2000/12/21 22:55:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.12 2000/12/22 18:57:49 petere Exp $
|
||||
CVS code repository
|
||||
Thomas Lockhart
|
||||
-->
|
||||
@ -655,7 +655,7 @@ $ which cvsup
|
||||
</programlisting>
|
||||
|
||||
and if you want to build a static binary to move to systems
|
||||
which may not have Modula-3 installed, try:
|
||||
that may not have Modula-3 installed, try:
|
||||
|
||||
<programlisting>
|
||||
# make M3FLAGS="-DNOGUI -DSTATIC"
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.45 2000/12/22 18:00:24 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.46 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -238,7 +238,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.45 2000/12/22 18:00:24 tg
|
||||
of <acronym>SQL92</acronym> are also supported.
|
||||
Although we strive for <acronym>SQL92</acronym> compliance,
|
||||
there are some aspects of the standard
|
||||
which are ill considered and which should not live through subsequent standards.
|
||||
that are ill considered and which should not live through subsequent standards.
|
||||
<productname>Postgres</productname> will not make great efforts to
|
||||
conform to these features; however, these tend to apply in little-used
|
||||
or obsure cases, and a typical user is not likely to run into them.
|
||||
@ -910,7 +910,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
|
||||
|
||||
<para>
|
||||
This type is defined by SQL92, but the definition exhibits
|
||||
fundamental deficiencies which renders the type nearly useless. In
|
||||
fundamental deficiencies that render the type nearly useless. In
|
||||
most cases, a combination of <type>date</type>,
|
||||
<type>time</type>, and <type>timestamp</type>
|
||||
should provide a complete range of date/time functionality
|
||||
@ -974,7 +974,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
|
||||
1999-01-08 04:05:06 -8:00
|
||||
</programlisting>
|
||||
|
||||
is a valid <type>timestamp</type> value, which is <acronym>ISO</acronym>-compliant.
|
||||
is a valid <type>timestamp</type> value that is <acronym>ISO</acronym>-compliant.
|
||||
In addition, the wide-spread format
|
||||
|
||||
<programlisting>
|
||||
@ -1267,7 +1267,7 @@ January 8 04:05:06 1999 PST
|
||||
|
||||
<para>
|
||||
To address these difficulties, we recommend using date/time
|
||||
types which contain both date and time when using time zones. We
|
||||
types that contain both date and time when using time zones. We
|
||||
recommend <emphasis>not</emphasis> using the SQL92 type TIME
|
||||
WITH TIME ZONE (though it is supported by
|
||||
<productname>Postgres</productname> for legacy applications and
|
||||
@ -1574,7 +1574,7 @@ January 8 04:05:06 1999 PST
|
||||
<title>Box</title>
|
||||
|
||||
<para>
|
||||
Boxes are represented by pairs of points which are opposite
|
||||
Boxes are represented by pairs of points that are opposite
|
||||
corners of the box.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.29 2000/11/11 13:53:49 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.30 2000/12/22 18:57:49 petere Exp $ -->
|
||||
|
||||
<appendix label="DG2" id="docguide">
|
||||
<title>Documentation</title>
|
||||
@ -435,7 +435,7 @@ CATALOG "docbook31/docbook.cat"
|
||||
<para>
|
||||
<productname>JadeTeX</productname> does not at the time of
|
||||
writing come with much of an installation guide, but there is a
|
||||
<filename>makefile</filename> which shows what is needed. It
|
||||
<filename>makefile</filename> that shows what is needed. It
|
||||
also includes a directory <filename>cooked</filename>, wherein
|
||||
you'll find some of the macro packages it needs, but not all, and
|
||||
not complete -- at least last we looked.
|
||||
@ -824,7 +824,7 @@ exit
|
||||
Not all documents have figures.
|
||||
You can grep the <acronym>SGML</acronym> source files for
|
||||
the string "<literal>graphic</literal>" to identify those parts of the
|
||||
documentation which may have figures. A few figures are replicated in
|
||||
documentation that may have figures. A few figures are replicated in
|
||||
various parts of the documentation.
|
||||
</para>
|
||||
</note>
|
||||
@ -969,7 +969,7 @@ exit
|
||||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Lop off the parts of the document which are not needed.
|
||||
Lop off the parts of the document that are not needed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -4,7 +4,7 @@
|
||||
<para>
|
||||
Indexes are commonly used to enhance database
|
||||
performance. They should be defined on table columns (or class
|
||||
attributes) which are used as qualifications in repetitive queries.
|
||||
attributes) that are used as qualifications in repetitive queries.
|
||||
Inappropriate use will result in slower performance, since update
|
||||
and insertion times are increased in the presence of indices.
|
||||
</para>
|
||||
@ -285,7 +285,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
<para>
|
||||
Thus, you may query a table by any combination of its columns, despite the
|
||||
fact that you don't have an index on these columns. The indexes are merely
|
||||
an implementational aid which each <acronym>RDBMS</acronym> offers
|
||||
an implementational aid that each <acronym>RDBMS</acronym> offers
|
||||
you, in order to cause
|
||||
commonly used queries to be done more efficiently.
|
||||
Some <acronym>RDBMS</acronym> may give you
|
||||
@ -306,14 +306,14 @@ CREATE MEMSTORE ON <table> COLUMNS <cols>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
So, if you want to use a combination of fields which is not unique as a
|
||||
So, if you want to use a combination of fields that is not unique as a
|
||||
secondary key, you really don't have to specify anything - just start
|
||||
retrieving by that combination! However, if you want to make the retrieval
|
||||
efficient, you'll have to resort to the means your
|
||||
<acronym>RDBMS</acronym> provider gives you
|
||||
- be it an index, my imaginary MEMSTORE command, or an intelligent
|
||||
<acronym>RDBMS</acronym>
|
||||
which creates indices without your knowledge based on the fact that you have
|
||||
that creates indices without your knowledge based on the fact that you have
|
||||
sent it many queries based on a specific combination of keys... (It learns
|
||||
from experience).
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.32 2000/12/20 17:23:39 thomas Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.33 2000/12/22 18:57:49 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%flattext-install-include[<productname>PostgreSQL</>]]> Installation Instructions</title>
|
||||
@ -204,7 +204,7 @@ su - postgres
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On systems which have <productname>PostgreSQL</> started at boot time, there is
|
||||
On systems that have <productname>PostgreSQL</> started at boot time, there is
|
||||
probably a start-up file that will accomplish the same thing. For
|
||||
example, on a Red Hat Linux system one might find that
|
||||
<screen>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.16 2000/12/21 22:55:27 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.17 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="jdbc">
|
||||
@ -1299,7 +1299,7 @@ java.lang.Object
|
||||
public class PGpath extends PGobject implements Serializable,
|
||||
Cloneable
|
||||
|
||||
This implements a path (a multiple segmented line, which may be
|
||||
This implements a path (a multiply segmented line, which may be
|
||||
closed)
|
||||
|
||||
Variables
|
||||
|
@ -1,31 +1,6 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.5 2000/09/29 20:21:34 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.6 2000/12/22 18:57:49 petere Exp $
|
||||
Indices and Keys
|
||||
|
||||
$Log: keys.sgml,v $
|
||||
Revision 1.5 2000/09/29 20:21:34 petere
|
||||
Add `id' attributes to all `chapter' and `sect1' tags, to generate useful
|
||||
names for the HTML files (e.g., not x4856.htm).
|
||||
|
||||
Revision 1.4 2000/08/23 05:59:02 thomas
|
||||
Fix several <ulink> tags which refer to e-mail addresses
|
||||
but were missing the "mailto:" prefix.
|
||||
Fix typo.
|
||||
Thanks to Neil Conway <nconway@klamath.dyndns.org> for the heads-up.
|
||||
|
||||
Revision 1.3 1998/12/29 02:24:16 thomas
|
||||
Clean up to ensure tag completion as required by the newest versions
|
||||
of Norm's Modular Style Sheets and jade/docbook.
|
||||
From Vince Vielhaber <vev@michvhf.com>.
|
||||
|
||||
Revision 1.2 1998/08/17 16:18:13 thomas
|
||||
Small sentence cleanups. Add tags for acronyms and products.
|
||||
|
||||
Revision 1.1 1998/08/15 06:52:03 thomas
|
||||
Nice exposition on indices and keys from Herouth Maoz which appeared
|
||||
on the mailing lists a while ago. Maybe slightly changed to fit docs.
|
||||
Will go into the User's Guide.
|
||||
|
||||
-->
|
||||
|
||||
<chapter id="keys">
|
||||
@ -165,7 +140,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
<para>
|
||||
Thus, you may query a table by any combination of its columns, despite the
|
||||
fact that you don't have an index on these columns. The indexes are merely
|
||||
an implementational aid which each <acronym>RDBMS</acronym> offers you, in order to cause
|
||||
an implementational aid that each <acronym>RDBMS</acronym> offers you, in order to cause
|
||||
commonly used queries to be done more efficiently. Some <acronym>RDBMS</acronym> may give you
|
||||
additional measures, such as keeping a key stored in main memory. They will
|
||||
have a special command, for example
|
||||
@ -181,13 +156,13 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
sequential scan!
|
||||
</para>
|
||||
<para>
|
||||
So, if you want to use a combination of fields which is not unique as a
|
||||
So, if you want to use a combination of fields that is not unique as a
|
||||
secondary key, you really don't have to specify anything - just start
|
||||
retrieving by that combination! However, if you want to make the retrieval
|
||||
efficient, you'll have to resort to the means your <acronym>RDBMS</acronym> provider gives you
|
||||
- be it an index, my imaginary MEMSTORE command, or an intelligent
|
||||
<acronym>RDBMS</acronym>
|
||||
which creates indices without your knowledge based on the fact that you have
|
||||
that creates indices without your knowledge based on the fact that you have
|
||||
sent it many queries based on a specific combination of keys... (It learns
|
||||
from experience).
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.20 2000/11/30 23:20:50 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.21 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpqplusplus">
|
||||
@ -8,7 +8,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.20 2000/11/30 23:20:
|
||||
<para>
|
||||
<filename>libpq++</filename> is the C++ API to
|
||||
<productname>Postgres</productname>.
|
||||
<filename>libpq++</filename> is a set of classes which allow
|
||||
<filename>libpq++</filename> is a set of classes that allow
|
||||
client programs to connect to the
|
||||
<productname>Postgres</productname> backend server. These connections
|
||||
come in two forms: a Database Class and a Large Object class.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.52 2000/12/21 18:47:05 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.53 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq-chapter">
|
||||
@ -33,7 +33,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.52 2000/12/21 18:47:05 momji
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Frontend programs which use <filename>libpq</filename> must include the
|
||||
Frontend programs that use <filename>libpq</filename> must include the
|
||||
header file <filename>libpq-fe.h</filename> and must link with the
|
||||
<filename>libpq</filename> library.
|
||||
</para>
|
||||
@ -116,7 +116,7 @@ PGconn *PQconnectdb(const char *conninfo)
|
||||
specified, the value for hostaddr gives the remote address; the value
|
||||
for host is ignored, unless Kerberos is used, in which case that value
|
||||
is used for Kerberos authentication. Note that authentication is likely
|
||||
to fail if libpq is passed a host name which is not the name of the
|
||||
to fail if libpq is passed a host name that is not the name of the
|
||||
machine at hostaddr.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.18 2000/09/29 20:21:34 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.19 2000/12/22 18:57:49 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="odbc">
|
||||
@ -29,11 +29,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.18 2000/09/29 20:21:34
|
||||
<para>
|
||||
<acronym>ODBC</acronym> (Open Database Connectivity) is an abstract
|
||||
<acronym>API</acronym>
|
||||
which allows you to write applications which can interoperate
|
||||
that allows you to write applications that can interoperate
|
||||
with various <acronym>RDBMS</acronym> servers.
|
||||
<acronym>ODBC</acronym> provides a product-neutral interface
|
||||
between frontend applications and database servers,
|
||||
allowing a user or developer to write applications which are
|
||||
allowing a user or developer to write applications that are
|
||||
transportable between servers from different manufacturers..
|
||||
</para>
|
||||
|
||||
@ -64,7 +64,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.18 2000/09/29 20:21:34
|
||||
|
||||
<para>
|
||||
For example. you could have <productname>MS SQL Server</productname>
|
||||
and <productname>Postgres</productname> servers which have
|
||||
and <productname>Postgres</productname> servers that have
|
||||
exactly the same data. Using <acronym>ODBC</acronym>,
|
||||
your Windows application would make exactly the
|
||||
same calls and the back end data source would look the same (to the Windows
|
||||
|
@ -18,7 +18,7 @@ In the following explanation, a
|
||||
<firstterm>byte</firstterm>
|
||||
is assumed to contain 8 bits. In addition, the term
|
||||
<firstterm>item</firstterm>
|
||||
refers to data which is stored in <productname>Postgres</productname> classes.
|
||||
refers to data that is stored in <productname>Postgres</productname> classes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -134,8 +134,8 @@ and
|
||||
<firstterm>special</firstterm>)
|
||||
represent byte offsets to the start of unallocated space, to the end
|
||||
of unallocated space, and to the start of <firstterm>special space</firstterm>.
|
||||
Special space is a region at the end of the page which is allocated at
|
||||
page initialization time and which contains information specific to an
|
||||
Special space is a region at the end of the page that is allocated at
|
||||
page initialization time and contains information specific to an
|
||||
access method. The last 2 bytes of the page header,
|
||||
<firstterm>opaque</firstterm>,
|
||||
encode the page size and information on the internal fragmentation of
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.6 2000/12/19 18:16:25 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.7 2000/12/22 18:57:50 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plperl">
|
||||
@ -7,7 +7,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.6 2000/12/19 18:16:25 peter
|
||||
|
||||
<para>
|
||||
PL/Perl allows you to write functions in the Perl programming
|
||||
language which may be used in SQL queries as if they were built into
|
||||
language that may be used in SQL queries as if they were built into
|
||||
<productname>Postgres</productname>.
|
||||
</para>
|
||||
|
||||
@ -137,7 +137,7 @@ SELECT name, empcomp(employee) FROM employee;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is an example of a function which will not work because file
|
||||
Here is an example of a function that will not work because file
|
||||
system operations are not allowed for security reasons:
|
||||
<programlisting>
|
||||
CREATE FUNCTION badfunc() RETURNS integer AS '
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.10 2000/09/29 20:21:34 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.11 2000/12/22 18:57:50 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plsql">
|
||||
@ -320,7 +320,7 @@ RENAME <replaceable>oldname</replaceable> TO <replaceable>newname</replaceable>;
|
||||
|
||||
<para>
|
||||
All expressions used in PL/pgSQL statements are processed using
|
||||
the backends executor. Expressions which appear to contain
|
||||
the backends executor. Expressions that appear to contain
|
||||
constants may in fact require run-time evaluation (e.g. 'now' for the
|
||||
datetime type) so
|
||||
it is impossible for the PL/pgSQL parser
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.14 2000/12/12 16:47:52 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.15 2000/12/22 18:57:50 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="query">
|
||||
@ -414,7 +414,7 @@ DELETE FROM classname;
|
||||
SELECT max(temp_lo) FROM weather;
|
||||
</programlisting>
|
||||
|
||||
If we want to know which city (or cities) that reading occurred in,
|
||||
If we want to know what city (or cities) that reading occurred in,
|
||||
we might try
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.14 2000/11/22 00:58:47 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.15 2000/12/22 18:57:50 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
@ -144,7 +144,7 @@
|
||||
platform system routines. In the latter case, the messages may
|
||||
vary between platforms, but should reflect similar
|
||||
information. These differences in messages will result in a
|
||||
<quote>failed</quote> regression test which can be validated by
|
||||
<quote>failed</quote> regression test that can be validated by
|
||||
inspection.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -177,7 +177,7 @@ PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There appear to be some systems which do not accept the
|
||||
There appear to be some systems that do not accept the
|
||||
recommended syntax for explicitly setting the local time zone
|
||||
rules; you may need to use a different <envar>PGTZ</envar>
|
||||
setting on such machines.
|
||||
@ -232,7 +232,7 @@ PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
|
||||
polygons whose vertices are represented as pairs of <type>double
|
||||
precision</type> numbers (decimal latitude and
|
||||
longitude). Initially, some tables are created and loaded with
|
||||
geographic data, then some views are created which join two
|
||||
geographic data, then some views are created that join two
|
||||
tables using the polygon intersection operator
|
||||
(<literal>##</literal>), then a select is done on the view.
|
||||
</para>
|
||||
|
@ -1288,7 +1288,7 @@ int * <REPLACEABLE CLASS="PARAMETER">attnum</REPLACEABLE>
|
||||
</TERM>
|
||||
<LISTITEM>
|
||||
<PARA>
|
||||
Array of numbers of the attributes which are to be changed
|
||||
Array of numbers of the attributes that are to be changed
|
||||
</PARA>
|
||||
</LISTITEM>
|
||||
</VARLISTENTRY>
|
||||
@ -2615,7 +2615,7 @@ TBD
|
||||
Server allocates memory in memory contexts in such way that allocations
|
||||
made in one context may be freed by context destruction without affecting
|
||||
allocations made in other contexts. All allocations (via <Function>palloc</Function>, etc) are
|
||||
made in the context which are chosen as current one. You'll get
|
||||
made in the context that is chosen as the current one. You'll get
|
||||
unpredictable results if you'll try to free (or reallocate) memory allocated
|
||||
not in current context.
|
||||
</Para>
|
||||
@ -2691,7 +2691,7 @@ rules, of course) without recursing.
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
Changes made by query Q are visible by queries which are started after
|
||||
Changes made by query Q are visible to queries that are started after
|
||||
query Q, no matter whether they are started inside Q (during the execution
|
||||
of Q) or after Q is done.
|
||||
</Para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.30 2000/12/21 22:55:27 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.31 2000/12/22 18:57:50 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="syntax">
|
||||
@ -71,7 +71,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.30 2000/12/21 22:55:27 pete
|
||||
|
||||
<para>
|
||||
The following are <productname>Postgres</productname>
|
||||
reserved words which are neither <acronym>SQL92</acronym>
|
||||
reserved words that are neither <acronym>SQL92</acronym>
|
||||
nor <acronym>SQL3</acronym> reserved words. These are allowed
|
||||
to be present as column labels, but not as identifiers:
|
||||
|
||||
@ -94,8 +94,8 @@ VACUUM VERBOSE
|
||||
|
||||
<para>
|
||||
The following are <productname>Postgres</productname>
|
||||
reserved words which are also <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> reserved words, and which
|
||||
reserved words that are also <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> reserved words, and that
|
||||
are allowed to be present as column labels, but not as identifiers:
|
||||
|
||||
<programlisting>
|
||||
@ -123,7 +123,7 @@ WHEN WHERE
|
||||
</programlisting>
|
||||
|
||||
The following are <productname>Postgres</productname>
|
||||
reserved words which are also <acronym>SQL92</acronym>
|
||||
reserved words that are also <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> reserved words:
|
||||
|
||||
<programlisting>
|
||||
@ -151,8 +151,8 @@ WHERE WITH WITHOUT WORK
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following are <acronym>SQL92</acronym> reserved key words which
|
||||
are not <productname>Postgres</productname> reserved key words, but which
|
||||
The following are <acronym>SQL92</acronym> reserved key words that
|
||||
are not <productname>Postgres</productname> reserved key words, but that
|
||||
if used as function names are always translated into the function
|
||||
<function>CHAR_LENGTH</function>:
|
||||
|
||||
@ -163,7 +163,7 @@ CHARACTER_LENGTH
|
||||
|
||||
<para>
|
||||
The following are <acronym>SQL92</acronym> or <acronym>SQL3</acronym>
|
||||
reserved key words which
|
||||
reserved key words that
|
||||
are not <productname>Postgres</productname> reserved key words, but
|
||||
if used as type names are always translated into an alternate, native type:
|
||||
|
||||
@ -190,7 +190,7 @@ DATETIME TIMESPAN
|
||||
<para>
|
||||
The following are either <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> reserved key words
|
||||
which are not key words in <productname>Postgres</productname>.
|
||||
that are not key words in <productname>Postgres</productname>.
|
||||
These have no proscribed usage in <productname>Postgres</productname>
|
||||
at the time of writing (version 7.0) but may become reserved key words in the
|
||||
future:
|
||||
@ -247,7 +247,7 @@ WHENEVER WRITE
|
||||
|
||||
<para>
|
||||
The following are <productname>Postgres</productname>
|
||||
non-reserved key words which are neither <acronym>SQL92</acronym>
|
||||
non-reserved key words that are neither <acronym>SQL92</acronym>
|
||||
nor <acronym>SQL3</acronym> non-reserved key words:
|
||||
|
||||
<programlisting>
|
||||
@ -274,7 +274,7 @@ VALID VERSION
|
||||
|
||||
<para>
|
||||
The following are <productname>Postgres</productname>
|
||||
non-reserved key words which are <acronym>SQL92</acronym>
|
||||
non-reserved key words that are <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> reserved key words:
|
||||
|
||||
<programlisting>
|
||||
@ -299,7 +299,7 @@ ZONE
|
||||
|
||||
<para>
|
||||
The following are <productname>Postgres</productname>
|
||||
non-reserved key words which are also either <acronym>SQL92</acronym>
|
||||
non-reserved key words that are also either <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> non-reserved key words:
|
||||
|
||||
<programlisting>
|
||||
@ -309,7 +309,7 @@ COMMITTED SERIALIZABLE TYPE
|
||||
|
||||
<para>
|
||||
The following are either <acronym>SQL92</acronym>
|
||||
or <acronym>SQL3</acronym> non-reserved key words which are not
|
||||
or <acronym>SQL3</acronym> non-reserved key words that are not
|
||||
key words of any kind in <productname>Postgres</productname>:
|
||||
|
||||
<programlisting>
|
||||
@ -362,7 +362,7 @@ UNCOMMITTED UNNAMED
|
||||
where the comment begins with "<literal>/*</literal>" and extends
|
||||
to the matching occurrence of "<literal>*/</literal>". These block
|
||||
comments nest, as specified in SQL99, so that one can comment out
|
||||
larger blocks of code which may contain existing block comments.
|
||||
larger blocks of code that may contain existing block comments.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
@ -411,7 +411,7 @@ INSERT INTO a SELECT * FROM a;
|
||||
|
||||
<blockquote>
|
||||
<para>
|
||||
Changes made by query Q are visible by queries which are started after
|
||||
Changes made by query Q are visible by queries that are started after
|
||||
query Q, no matter whether they are started inside Q (during the
|
||||
execution of Q) or after Q is done.
|
||||
</para>
|
||||
|
@ -36,7 +36,7 @@ implicit type conversion and coercion.
|
||||
<para>
|
||||
<acronym>SQL</acronym> is a strongly typed language. That is, every data item
|
||||
has an associated data type which determines its behavior and allowed usage.
|
||||
<productname>Postgres</productname> has an extensible type system which is
|
||||
<productname>Postgres</productname> has an extensible type system that is
|
||||
much more general and flexible than other <acronym>RDBMS</acronym> implementations.
|
||||
Hence, most type conversion behavior in <productname>Postgres</productname>
|
||||
should be governed by general rules rather than by ad-hoc heuristics to allow
|
||||
@ -265,7 +265,7 @@ If only one candidate remains, use it; else continue to the next step.
|
||||
</step>
|
||||
<step performance="required">
|
||||
<para>
|
||||
Run through all candidates and keep those which accept preferred types at
|
||||
Run through all candidates and keep those that accept preferred types at
|
||||
the most positions where type coercion will be required.
|
||||
Keep all candidates if none accept preferred types.
|
||||
If only one candidate remains, use it; else continue to the next step.
|
||||
@ -474,7 +474,7 @@ If only one candidate remains, use it; else continue to the next step.
|
||||
</step>
|
||||
<step performance="required">
|
||||
<para>
|
||||
Run through all candidates and keep those which accept preferred types at
|
||||
Run through all candidates and keep those that accept preferred types at
|
||||
the most positions where type coercion will be required.
|
||||
Keep all candidates if none accept preferred types.
|
||||
If only one candidate remains, use it; else continue to the next step.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.24 2000/12/21 22:55:27 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.25 2000/12/22 18:57:50 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
@ -351,7 +351,7 @@ SELECT clean_EMP();
|
||||
<title>Internal Functions</title>
|
||||
|
||||
<para>
|
||||
Internal functions are functions written in C which have been statically
|
||||
Internal functions are functions written in C that have been statically
|
||||
linked into the <productname>Postgres</productname> backend
|
||||
process. The AS
|
||||
clause gives the C-language name of the function, which need not be the
|
||||
@ -397,7 +397,7 @@ SELECT clean_EMP();
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The string which specifies the object file (the first string in the AS
|
||||
The string that specifies the object file (the first string in the AS
|
||||
clause) should be the <emphasis>full path</emphasis> of the object
|
||||
code file for the function, bracketed by single quote marks. If a
|
||||
link symbol is given in the AS clause, the link symbol should also be
|
||||
|
Loading…
x
Reference in New Issue
Block a user