Commit 84956e71 authored by Peter Eisentraut's avatar Peter Eisentraut

Markup additions and spell check. (covers User's Guide)

parent ba708ea3
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.11 2001/05/12 22:51:34 petere Exp $ --> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.12 2001/09/09 17:21:44 petere Exp $ -->
<chapter id="arrays"> <chapter id="arrays">
<title>Arrays</title> <title>Arrays</title>
...@@ -9,7 +9,7 @@ ...@@ -9,7 +9,7 @@
<para> <para>
<productname>Postgres</productname> allows columns of a table to be <productname>Postgres</productname> allows columns of a table to be
defined as variable-length multi-dimensional arrays. Arrays of any defined as variable-length multidimensional arrays. Arrays of any
built-in type or user-defined type can be created. To illustrate built-in type or user-defined type can be created. To illustrate
their use, we create this table: their use, we create this table:
<programlisting> <programlisting>
......
This diff is collapsed.
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.19 2001/06/18 19:05:11 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.20 2001/09/09 17:21:58 petere Exp $
Date/time details Date/time details
--> -->
...@@ -225,7 +225,7 @@ Date/time details ...@@ -225,7 +225,7 @@ Date/time details
<row> <row>
<entry>DNT</entry> <entry>DNT</entry>
<entry>+1:00 </entry> <entry>+1:00 </entry>
<entry>Dansk Normal Tid</entry> <entry><foreignphrase>Dansk Normal Tid</foreignphrase></entry>
</row> </row>
<row> <row>
<entry>FST</entry> <entry>FST</entry>
......
This diff is collapsed.
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
--> -->
<sect1 id="history"> <sect1 id="history">
...@@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet ...@@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
California at Berkeley. With over a decade of California at Berkeley. With over a decade of
development behind it, <productname>PostgreSQL</productname> development behind it, <productname>PostgreSQL</productname>
is the most advanced open-source database available anywhere, is the most advanced open-source database available anywhere,
offering multi-version concurrency control, supporting almost offering multiversion concurrency control, supporting almost
all SQL constructs (including subselects, transactions, and all SQL constructs (including subselects, transactions, and
user-defined types and functions), and having a wide range of user-defined types and functions), and having a wide range of
language bindings available (including C, C++, Java, Perl, Tcl, and Python). language bindings available (including C, C++, Java, Perl, Tcl, and Python).
...@@ -72,7 +72,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet ...@@ -72,7 +72,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
Finally, Finally,
<ulink url="http://www.illustra.com/">Illustra Information Technologies</ulink> <ulink url="http://www.illustra.com/">Illustra Information Technologies</ulink>
(since merged into (since merged into
<ulink url="http://www.informix.com/">Informix</ulink>) <ulink url="http://www.informix.com/"><productname>Informix</productname></ulink>)
picked up picked up
the code and commercialized it. the code and commercialized it.
<productname>Postgres</productname> became the primary data manager <productname>Postgres</productname> became the primary data manager
...@@ -141,7 +141,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet ...@@ -141,7 +141,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
<para> <para>
A new front-end library, <filename>libpgtcl</filename>, A new front-end library, <filename>libpgtcl</filename>,
supported <acronym>Tcl</acronym>-based clients. A sample shell, supported <acronym>Tcl</acronym>-based clients. A sample shell,
pgtclsh, provided new Tcl commands to interface <command>pgtclsh</command>, provided new Tcl commands to interface
<application>tcl</application> <application>tcl</application>
programs with the <productname>Postgres95</productname> backend. programs with the <productname>Postgres95</productname> backend.
</para> </para>
...@@ -211,7 +211,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet ...@@ -211,7 +211,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
Table-level locking has been replaced with multi-version concurrency control, Table-level locking has been replaced with multiversion concurrency control,
which allows readers to continue reading consistent data during writer activity which allows readers to continue reading consistent data during writer activity
and enables hot backups from pg_dump while the database stays available for and enables hot backups from pg_dump while the database stays available for
queries. queries.
......
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.22 2001/08/24 14:07:48 petere Exp $ --> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.23 2001/09/09 17:21:59 petere Exp $ -->
<chapter id="indexes"> <chapter id="indexes">
<title id="indexes-title">Indexes</title> <title id="indexes-title">Indexes</title>
...@@ -571,7 +571,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r ...@@ -571,7 +571,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
retrieving by that combination! However, if you want to make the retrieval retrieving by that combination! However, if you want to make the retrieval
efficient, you'll have to resort to the means your efficient, you'll have to resort to the means your
<acronym>RDBMS</acronym> provider gives you <acronym>RDBMS</acronym> provider gives you
- be it an index, my imaginary MEMSTORE command, or an intelligent - be it an index, my imaginary <literal>MEMSTORE</literal> command, or an intelligent
<acronym>RDBMS</acronym> <acronym>RDBMS</acronym>
that creates indexes without your knowledge based on the fact that you have that creates indexes without your knowledge based on the fact that you have
sent it many queries based on a specific combination of keys... (It learns sent it many queries based on a specific combination of keys... (It learns
...@@ -629,7 +629,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r ...@@ -629,7 +629,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
that involve deciding what predicate(s) match the workload/query in that involve deciding what predicate(s) match the workload/query in
some useful way. For those who are into database theory, the problems some useful way. For those who are into database theory, the problems
are basically analogous to the corresponding materialized view are basically analogous to the corresponding materialized view
problems, albeit with different cost parameters and formulae. These problems, albeit with different cost parameters and formulas. These
are, in the general case, hard problems for the standard ordinal are, in the general case, hard problems for the standard ordinal
<acronym>SQL</acronym> <acronym>SQL</acronym>
types; they're super-hard problems with black-box extension types, types; they're super-hard problems with black-box extension types,
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
--> -->
<chapter id="inherit"> <chapter id="inherit">
...@@ -37,7 +37,7 @@ CREATE TABLE capitals ( ...@@ -37,7 +37,7 @@ CREATE TABLE capitals (
<note> <note>
<para> <para>
The inheritance hierarchy is a actually a directed acyclic graph. The inheritance hierarchy is actually a directed acyclic graph.
</para> </para>
</note> </note>
</para> </para>
...@@ -100,7 +100,7 @@ SELECT name, altitude ...@@ -100,7 +100,7 @@ SELECT name, altitude
<para> <para>
In some cases you may wish to know which table a particular tuple In some cases you may wish to know which table a particular tuple
originated from. There is a system column called originated from. There is a system column called
<quote>TABLEOID</quote> in each table which can tell you the <structfield>TABLEOID</structfield> in each table which can tell you the
originating table: originating table:
<programlisting> <programlisting>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.11 2001/09/09 17:21:59 petere Exp $
--> -->
<copyright> <copyright>
...@@ -42,7 +42,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 peter ...@@ -42,7 +42,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 peter
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS-IS" BASIS, AND THE UNIVERSITY OF PROVIDED HEREUNDER IS ON AN "AS-IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTAINANCE, SUPPORT, CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS. UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
</para> </para>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.13 2001/02/04 15:28:18 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
--> -->
<Chapter Id="manage"> <Chapter Id="manage">
<Title>Managing a Database</Title> <Title>Managing a Database</Title>
<Note> <comment>
<Para>
This section is currently a thinly disguised copy of the This section is currently a thinly disguised copy of the
Tutorial. Needs to be augmented. Tutorial. Needs to be augmented.
- thomas 1998-01-12 - thomas 1998-01-12
</Para> </comment>
</Note>
<Para> <Para>
Although the <FirstTerm>site administrator</FirstTerm> is responsible for overall management Although the <FirstTerm>site administrator</FirstTerm> is responsible for overall management
...@@ -89,9 +87,9 @@ ERROR: CREATE DATABASE: Permission denied. ...@@ -89,9 +87,9 @@ ERROR: CREATE DATABASE: Permission denied.
Alternate database locations are created and referenced by an environment variable Alternate database locations are created and referenced by an environment variable
which gives the absolute path to the intended storage location. which gives the absolute path to the intended storage location.
This environment variable must have been defined before the postmaster was started This environment variable must have been defined before the postmaster was started
and the location it points to must be writable by the postgres administrator account. and the location it points to must be writable by the administrator account.
Consult with the site administrator Consult with the site administrator
regarding preconfigured alternate database locations. regarding preconfigured alternative database locations.
Any valid environment variable name may be used to reference an alternate location, Any valid environment variable name may be used to reference an alternate location,
although using variable names with a prefix of <envar>PGDATA</envar> is recommended although using variable names with a prefix of <envar>PGDATA</envar> is recommended
to avoid confusion to avoid confusion
...@@ -101,7 +99,7 @@ ERROR: CREATE DATABASE: Permission denied. ...@@ -101,7 +99,7 @@ ERROR: CREATE DATABASE: Permission denied.
<Note> <Note>
<Para> <Para>
In previous versions of <ProductName>Postgres</ProductName>, In previous versions of <ProductName>Postgres</ProductName>,
it was also permissable to use an absolute path name to specify it was also permissible to use an absolute path name to specify
an alternate storage location. an alternate storage location.
Although the environment variable style of specification Although the environment variable style of specification
is to be preferred since it allows the site administrator more flexibility in is to be preferred since it allows the site administrator more flexibility in
...@@ -181,7 +179,7 @@ enter, edit, and execute <Acronym>SQL</Acronym> commands. ...@@ -181,7 +179,7 @@ enter, edit, and execute <Acronym>SQL</Acronym> commands.
</ListItem> </ListItem>
<ListItem> <ListItem>
<Para> <Para>
writing a C program using the LIBPQ subroutine writing a C program using the <application>LIBPQ</application> subroutine
library. This allows you to submit <Acronym>SQL</Acronym> commands library. This allows you to submit <Acronym>SQL</Acronym> commands
from C and get answers and status messages back to from C and get answers and status messages back to
your program. This interface is discussed further your program. This interface is discussed further
...@@ -213,7 +211,7 @@ mydb=> ...@@ -213,7 +211,7 @@ mydb=>
</Para> </Para>
<Para> <Para>
This prompt indicates that psql is listening This prompt indicates that <command>psql</command> is listening
to you and that you can type <Acronym>SQL</Acronym> queries into a to you and that you can type <Acronym>SQL</Acronym> queries into a
workspace maintained by the terminal monitor. workspace maintained by the terminal monitor.
The <Application>psql</Application> program responds to escape codes that begin The <Application>psql</Application> program responds to escape codes that begin
...@@ -235,7 +233,7 @@ mydb=> \g ...@@ -235,7 +233,7 @@ mydb=> \g
terminate your query with a semicolon, the "<literal>\g</literal>" is not terminate your query with a semicolon, the "<literal>\g</literal>" is not
necessary. necessary.
<Application>psql</Application> will automatically process semicolon terminated queries. <Application>psql</Application> will automatically process semicolon terminated queries.
To read queries from a file, say myFile, instead of To read queries from a file, say <filename>myFile</filename>, instead of
entering them interactively, type: entering them interactively, type:
<ProgramListing> <ProgramListing>
mydb=> \i fileName mydb=> \i fileName
...@@ -247,7 +245,7 @@ mydb=> \q ...@@ -247,7 +245,7 @@ mydb=> \q
</ProgramListing> </ProgramListing>
and <Application>psql</Application> will quit and return you to your command and <Application>psql</Application> will quit and return you to your command
shell. (For more escape codes, type <Command>\?</Command> at the psql shell. (For more escape codes, type <Command>\?</Command> at the <command>psql</command>
prompt.) prompt.)
White space (i.e., spaces, tabs and newlines) may be White space (i.e., spaces, tabs and newlines) may be
used freely in <Acronym>SQL</Acronym> queries. Single-line comments are denoted by used freely in <Acronym>SQL</Acronym> queries. Single-line comments are denoted by
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.16 2001/07/09 22:18:33 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.17 2001/09/09 17:21:59 petere Exp $
--> -->
<chapter id="mvcc"> <chapter id="mvcc">
...@@ -593,7 +593,7 @@ ERROR: Can't serialize access due to concurrent update ...@@ -593,7 +593,7 @@ ERROR: Can't serialize access due to concurrent update
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
GiST and R-Tree indexes <acronym>GiST</acronym> and R-Tree indexes
</term> </term>
<listitem> <listitem>
<para> <para>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.15 2001/09/09 17:21:59 petere Exp $
--> -->
<sect1 id="notation"> <sect1 id="notation">
...@@ -38,10 +38,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe ...@@ -38,10 +38,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
<para> <para>
Examples will show commands executed from various accounts and programs. Examples will show commands executed from various accounts and programs.
Commands executed from a Unix shell may be preceeded with a dollar sign Commands executed from a Unix shell may be preceded with a dollar sign
(<quote><literal>$</literal></quote>). Commands executed from particular user (<quote><literal>$</literal></quote>). Commands executed from particular user
accounts such as root or postgres are specially flagged and explained. accounts such as <systemitem>root</> or <systemitem>postgres</> are specially flagged and explained.
<acronym>SQL</acronym> commands may be preceeded with <acronym>SQL</acronym> commands may be preceded with
<quote><literal>=&gt;</literal></quote> <quote><literal>=&gt;</literal></quote>
or will have no leading prompt, depending on the context. or will have no leading prompt, depending on the context.
</para> </para>
...@@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe ...@@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
<note> <note>
<para> <para>
The notation for The notation for
flagging commands is not universally consistant throughout the flagging commands is not universally consistent throughout the
documentation set. documentation set.
Please report problems to the documentation mailing list Please report problems to the documentation mailing list
<email>pgsql-docs@postgresql.org</email>. <email>pgsql-docs@postgresql.org</email>.
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.7 2001/06/22 18:53:36 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.8 2001/09/09 17:21:59 petere Exp $
--> -->
<chapter id="performance-tips"> <chapter id="performance-tips">
...@@ -109,9 +109,9 @@ Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148) ...@@ -109,9 +109,9 @@ Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
select * from pg_class where relname = 'tenk1'; select * from pg_class where relname = 'tenk1';
</programlisting> </programlisting>
you'll find out that tenk1 has 233 disk you will find out that <classname>tenk1</classname> has 233 disk
pages and 10000 tuples. So the cost is estimated at 233 page pages and 10000 tuples. So the cost is estimated at 233 page
reads, defined as 1.0 apiece, plus 10000 * cpu_tuple_cost which is reads, defined as 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is
currently 0.01 (try <command>show cpu_tuple_cost</command>). currently 0.01 (try <command>show cpu_tuple_cost</command>).
</para> </para>
...@@ -152,7 +152,7 @@ Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.32 rows=47 width=148) ...@@ -152,7 +152,7 @@ Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.32 rows=47 width=148)
and you will see that if we make the WHERE condition selective and you will see that if we make the WHERE condition selective
enough, the planner will enough, the planner will
eventually decide that an indexscan is cheaper than a sequential scan. eventually decide that an index scan is cheaper than a sequential scan.
This plan will only have to visit 50 tuples because of the index, This plan will only have to visit 50 tuples because of the index,
so it wins despite the fact that each individual fetch is more expensive so it wins despite the fact that each individual fetch is more expensive
than reading a whole disk page sequentially. than reading a whole disk page sequentially.
...@@ -169,7 +169,7 @@ NOTICE: QUERY PLAN: ...@@ -169,7 +169,7 @@ NOTICE: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.44 rows=1 width=148) Index Scan using tenk1_unique1 on tenk1 (cost=0.00..173.44 rows=1 width=148)
</programlisting> </programlisting>
The added clause "stringu1 = 'xxx'" reduces the output-rows estimate, The added clause <literal>stringu1 = 'xxx'</literal> reduces the output-rows estimate,
but not the cost because we still have to visit the same set of tuples. but not the cost because we still have to visit the same set of tuples.
</para> </para>
...@@ -190,18 +190,18 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296) ...@@ -190,18 +190,18 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
</para> </para>
<para> <para>
In this nested-loop join, the outer scan is the same indexscan we had In this nested-loop join, the outer scan is the same index scan we had
in the example before last, and so its cost and row count are the same in the example before last, and so its cost and row count are the same
because we are applying the "unique1 &lt; 50" WHERE clause at that node. because we are applying the "unique1 &lt; 50" WHERE clause at that node.
The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't
affect the outer scan's row count. For the inner scan, the affect row count of the outer scan. For the inner scan, the unique2 value of the
current current
outer-scan tuple's unique2 value is plugged into the inner indexscan outer-scan tuple is plugged into the inner index scan
to produce an indexqual like to produce an index qualification like
"t2.unique2 = <replaceable>constant</replaceable>". So we get the "t2.unique2 = <replaceable>constant</replaceable>". So we get the
same inner-scan plan and costs that we'd get from, say, "explain select same inner-scan plan and costs that we'd get from, say, <literal>explain select
* from tenk2 where unique2 = 42". The loop node's costs are then set * from tenk2 where unique2 = 42</literal>. The costs of the loop node are then set
on the basis of the outer scan's cost, plus one repetition of the on the basis of the cost of the outer scan, plus one repetition of the
inner scan for each outer tuple (47 * 2.01, here), plus a little CPU inner scan for each outer tuple (47 * 2.01, here), plus a little CPU
time for join processing. time for join processing.
</para> </para>
...@@ -212,7 +212,7 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296) ...@@ -212,7 +212,7 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
in general you can have WHERE clauses that mention both relations and in general you can have WHERE clauses that mention both relations and
so can only be applied at the join point, not to either input scan. so can only be applied at the join point, not to either input scan.
For example, if we added "WHERE ... AND t1.hundred &lt; t2.hundred", For example, if we added "WHERE ... AND t1.hundred &lt; t2.hundred",
that'd decrease the output row count of the join node, but not change that would decrease the output row count of the join node, but not change
either input scan. either input scan.
</para> </para>
...@@ -237,13 +237,13 @@ Hash Join (cost=173.44..557.03 rows=47 width=296) ...@@ -237,13 +237,13 @@ Hash Join (cost=173.44..557.03 rows=47 width=296)
(cost=0.00..173.32 rows=47 width=148) (cost=0.00..173.32 rows=47 width=148)
</programlisting> </programlisting>
This plan proposes to extract the 50 interesting rows of tenk1 This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
using ye same olde indexscan, stash them into an in-memory hash table, using ye same olde index scan, stash them into an in-memory hash table,
and then do a sequential scan of tenk2, probing into the hash table and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
for possible matches of "t1.unique2 = t2.unique2" at each tenk2 tuple. for possible matches of "t1.unique2 = t2.unique2" at each <classname>tenk2</classname> tuple.
The cost to read tenk1 and set up the hash table is entirely start-up The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
cost for the hash join, since we won't get any tuples out until we can cost for the hash join, since we won't get any tuples out until we can
start reading tenk2. The total time estimate for the join also start reading <classname>tenk2</classname>. The total time estimate for the join also
includes a hefty charge for CPU time to probe the hash table includes a hefty charge for CPU time to probe the hash table
10000 times. Note, however, that we are NOT charging 10000 times 173.32; 10000 times. Note, however, that we are NOT charging 10000 times 173.32;
the hash table setup is only done once in this plan type. the hash table setup is only done once in this plan type.
...@@ -302,8 +302,8 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id; ...@@ -302,8 +302,8 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
annoyingly long time. When there are too many input tables, the annoyingly long time. When there are too many input tables, the
<productname>Postgres</productname> planner will switch from exhaustive <productname>Postgres</productname> planner will switch from exhaustive
search to a <firstterm>genetic</firstterm> probabilistic search search to a <firstterm>genetic</firstterm> probabilistic search
through a limited number of possibilities. (The switchover threshold is through a limited number of possibilities. (The switch-over threshold is
set by the GEQO_THRESHOLD run-time set by the <varname>GEQO_THRESHOLD</varname> run-time
parameter described in the <citetitle>Administrator's Guide</citetitle>.) parameter described in the <citetitle>Administrator's Guide</citetitle>.)
The genetic search takes less time, but it won't The genetic search takes less time, but it won't
necessarily find the best possible plan. necessarily find the best possible plan.
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 petere Exp $
--> -->
<sect1 id="bug-reporting"> <sect1 id="bug-reporting">
...@@ -137,10 +137,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl ...@@ -137,10 +137,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
query. query.
You are encouraged to You are encouraged to
minimize the size of your example, but this is not absolutely necessary. minimize the size of your example, but this is not absolutely necessary.
If the bug is reproduceable, we will find it either way. If the bug is reproducible, we will find it either way.
</para> </para>
<para> <para>
If your application uses some other client interface, such as PHP, then If your application uses some other client interface, such as <applicatioN>PHP</>, then
please try to isolate the offending queries. We will probably not set up a please try to isolate the offending queries. We will probably not set up a
web server to reproduce your problem. In any case remember to provide web server to reproduce your problem. In any case remember to provide
the exact input files, do not guess that the problem happens for the exact input files, do not guess that the problem happens for
...@@ -174,7 +174,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl ...@@ -174,7 +174,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
The output you expected is very important to state. If you just write The output you expected is very important to state. If you just write
"This command gives me that output." or "This is not "This command gives me that output." or "This is not
what I expected.", we might run it ourselves, scan the output, and what I expected.", we might run it ourselves, scan the output, and
think it looks okay and is exactly what we expected. We should not have to think it looks OK and is exactly what we expected. We should not have to
spend the time to decode the exact semantics behind your commands. spend the time to decode the exact semantics behind your commands.
Especially refrain from merely saying that "This is not what SQL says/Oracle Especially refrain from merely saying that "This is not what SQL says/Oracle
does." Digging out the correct behavior from <acronym>SQL</acronym> does." Digging out the correct behavior from <acronym>SQL</acronym>
...@@ -188,7 +188,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl ...@@ -188,7 +188,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
<para> <para>
Any command line options and other start-up options, including concerned Any command line options and other start-up options, including concerned
environment variables or configuration files that you changed from the environment variables or configuration files that you changed from the
default. Again, be exact. If you are using a pre-packaged default. Again, be exact. If you are using a prepackaged
distribution that starts the database server at boot time, you should try distribution that starts the database server at boot time, you should try
to find out how that is done. to find out how that is done.
</para> </para>
...@@ -212,7 +212,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl ...@@ -212,7 +212,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
old enough. You can also look into the <filename>README</filename> file old enough. You can also look into the <filename>README</filename> file
in the source directory or at the in the source directory or at the
name of your distribution file or package name. name of your distribution file or package name.
If you run a pre-packaged version, such as RPMs, say so, including any If you run a prepackaged version, such as RPMs, say so, including any
subversion the package may have. If you are talking about a CVS subversion the package may have. If you are talking about a CVS
snapshot, mention that, including its date and time. snapshot, mention that, including its date and time.
</para> </para>
......
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.8 2001/08/30 08:16:42 ishii Exp $ --> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.9 2001/09/09 17:21:59 petere Exp $ -->
<chapter id="queries"> <chapter id="queries">
<title>Queries</title> <title>Queries</title>
...@@ -85,7 +85,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r ...@@ -85,7 +85,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
A table reference may be a table name or a derived table such as a A table reference may be a table name or a derived table such as a
subquery, a table join, or complex combinations of these. If more subquery, a table join, or complex combinations of these. If more
than one table reference is listed in the FROM clause they are than one table reference is listed in the FROM clause they are
CROSS JOINed (see below) to form the derived table that may then cross-joined (see below) to form the derived table that may then
be subject to transformations by the WHERE, GROUP BY, and HAVING be subject to transformations by the WHERE, GROUP BY, and HAVING
clauses and is finally the result of the overall table expression. clauses and is finally the result of the overall table expression.
</para> </para>
...@@ -150,7 +150,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r ...@@ -150,7 +150,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Qualified JOINs</term> <term>Qualified joins</term>
<listitem> <listitem>
<indexterm> <indexterm>
...@@ -166,7 +166,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r ...@@ -166,7 +166,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
<para> <para>
The words <token>INNER</token> and <token>OUTER</token> are The words <token>INNER</token> and <token>OUTER</token> are
optional for all JOINs. <token>INNER</token> is the default; optional for all joins. <token>INNER</token> is the default;
<token>LEFT</token>, <token>RIGHT</token>, and <token>LEFT</token>, <token>RIGHT</token>, and
<token>FULL</token> imply an OUTER JOIN. <token>FULL</token> imply an OUTER JOIN.
</para> </para>
...@@ -281,7 +281,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r ...@@ -281,7 +281,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
<para> <para>
Joins of all types can be chained together or nested: either Joins of all types can be chained together or nested: either
or both of <replaceable>T1</replaceable> and or both of <replaceable>T1</replaceable> and
<replaceable>T2</replaceable> may be JOINed tables. Parentheses <replaceable>T2</replaceable> may be joined tables. Parentheses
may be used around JOIN clauses to control the join order. In the may be used around JOIN clauses to control the join order. In the
absence of parentheses, JOIN clauses nest left-to-right. absence of parentheses, JOIN clauses nest left-to-right.
</para> </para>
...@@ -479,7 +479,7 @@ FROM a NATURAL JOIN b WHERE b.val &gt; 5 ...@@ -479,7 +479,7 @@ FROM a NATURAL JOIN b WHERE b.val &gt; 5
Which one of these you use is mainly a matter of style. The JOIN Which one of these you use is mainly a matter of style. The JOIN
syntax in the FROM clause is probably not as portable to other syntax in the FROM clause is probably not as portable to other
products. For outer joins there is no choice in any case: they products. For outer joins there is no choice in any case: they
must be done in the FROM clause. An outer join's ON/USING clause must be done in the FROM clause. A ON/USING clause of an outer join
is <emphasis>not</> equivalent to a WHERE condition, because it is <emphasis>not</> equivalent to a WHERE condition, because it
determines the addition of rows (for unmatched input rows) as well determines the addition of rows (for unmatched input rows) as well
as the removal of rows from the final result. as the removal of rows from the final result.
...@@ -505,16 +505,18 @@ FROM FDT WHERE ...@@ -505,16 +505,18 @@ FROM FDT WHERE
</programlisting> </programlisting>
<para> <para>
In the examples above, FDT is the table derived in the FROM In the examples above, <literal>FDT</literal> is the table derived
clause. Rows that do not meet the search condition of the where in the FROM clause. Rows that do not meet the search condition of
clause are eliminated from FDT. Notice the use of scalar the where clause are eliminated from
subqueries as value expressions. Just like <literal>FDT</literal>. Notice the use of scalar subqueries as
any other query, the subqueries can employ complex table value expressions. Just like any other query, the subqueries can
expressions. Notice how FDT is referenced in the subqueries. employ complex table expressions. Notice how
Qualifying C1 as FDT.C1 is only necessary if C1 is also the name of a <literal>FDT</literal> is referenced in the subqueries.
column in the derived input table of the subquery. Qualifying the Qualifying <literal>C1</> as <literal>FDT.C1</> is only necessary
column name adds clarity even when it is not needed. This shows how if <literal>C1</> is also the name of a column in the derived
the column naming scope of an outer query extends into its inner queries. input table of the subquery. Qualifying the column name adds
clarity even when it is not needed. This shows how the column
naming scope of an outer query extends into its inner queries.
</para> </para>
</sect2> </sect2>
...@@ -569,7 +571,7 @@ SELECT pid, p.name, (sum(s.units) * p.price) AS sales ...@@ -569,7 +571,7 @@ SELECT pid, p.name, (sum(s.units) * p.price) AS sales
FROM products p LEFT JOIN sales s USING ( pid ) FROM products p LEFT JOIN sales s USING ( pid )
GROUP BY pid, p.name, p.price; GROUP BY pid, p.name, p.price;
</programlisting> </programlisting>
In this example, the columns pid, p.name, and p.price must be in In this example, the columns <literal>pid</literal>, <literal>p.name</literal>, and <literal>p.price</literal> must be in
the GROUP BY clause since they are referenced in the query select the GROUP BY clause since they are referenced in the query select
list. The column s.units does not have to be in the GROUP BY list list. The column s.units does not have to be in the GROUP BY list
since it is only used in an aggregate expression since it is only used in an aggregate expression
...@@ -868,12 +870,12 @@ SELECT a, b FROM table1 ORDER BY a + b; ...@@ -868,12 +870,12 @@ SELECT a, b FROM table1 ORDER BY a + b;
SELECT a AS b FROM table1 ORDER BY a; SELECT a AS b FROM table1 ORDER BY a;
</programlisting> </programlisting>
But these extensions do not work in queries involving UNION, INTERSECT, But these extensions do not work in queries involving UNION, INTERSECT,
or EXCEPT, and are not portable to other DBMSes. or EXCEPT, and are not portable to other <acronym>DBMS</acronym>.
</para> </para>
<para> <para>
Each column specification may be followed by an optional ASC or Each column specification may be followed by an optional <token>ASC</token> or
DESC to set the sort direction. ASC is default. Ascending order <token>DESC</token> to set the sort direction. <token>ASC</token> is default. Ascending order
puts smaller values first, where <quote>smaller</quote> is defined puts smaller values first, where <quote>smaller</quote> is defined
in terms of the <literal>&lt;</literal> operator. Similarly, in terms of the <literal>&lt;</literal> operator. Similarly,
descending order is determined with the <literal>&gt;</literal> descending order is determined with the <literal>&gt;</literal>
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.45 2001/08/26 21:17:12 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.46 2001/09/09 17:21:59 petere Exp $
--> -->
<chapter id="sql-syntax"> <chapter id="sql-syntax">
...@@ -462,7 +462,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -462,7 +462,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<listitem> <listitem>
<para> <para>
"$" (dollar) cannot be a single-character operator, although it "$" (dollar) cannot be a single-character operator, although it
can be part of a multi-character operator name. can be part of a multiple-character operator name.
</para> </para>
</listitem> </listitem>
...@@ -476,7 +476,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -476,7 +476,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<listitem> <listitem>
<para> <para>
A multi-character operator name cannot end in "+" or "-", A multiple-character operator name cannot end in "+" or "-",
unless the name also contains at least one of these characters: unless the name also contains at least one of these characters:
<literallayout> <literallayout>
~ ! @ # % ^ &amp; | ` ? $ ~ ! @ # % ^ &amp; | ` ? $
...@@ -600,7 +600,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -600,7 +600,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<para> <para>
Alternatively, C-style block comments can be used: Alternatively, C-style block comments can be used:
<programlisting> <programlisting>
/* multi-line comment /* multiline comment
* with nesting: /* nested block comment */ * with nesting: /* nested block comment */
*/ */
</programlisting> </programlisting>
...@@ -634,7 +634,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -634,7 +634,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term>oid</term> <term><structfield>oid</></term>
<listitem> <listitem>
<para> <para>
<indexterm> <indexterm>
...@@ -649,20 +649,22 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -649,20 +649,22 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>tableoid</term> <term><structfield>tableoid</></term>
<listitem> <listitem>
<para> <para>
The OID of the table containing this row. This attribute is The OID of the table containing this row. This attribute is
particularly handy for queries that select from inheritance particularly handy for queries that select from inheritance
hierarchies, since without it, it's difficult to tell which hierarchies, since without it, it's difficult to tell which
individual table a row came from. The tableoid can be joined individual table a row came from. The
against the OID attribute of pg_class to obtain the table name. <structfield>tableoid</structfield> can be joined against the
<structfield>oid</structfield> column of
<classname>pg_class</classname> to obtain the table name.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>xmin</term> <term><structfield>xmin</></term>
<listitem> <listitem>
<para> <para>
The identity (transaction ID) of the inserting transaction for The identity (transaction ID) of the inserting transaction for
...@@ -673,7 +675,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -673,7 +675,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>cmin</term> <term><structfield>cmin</></term>
<listitem> <listitem>
<para> <para>
The command identifier (starting at zero) within the inserting The command identifier (starting at zero) within the inserting
...@@ -683,7 +685,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -683,7 +685,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>xmax</term> <term><structfield>xmax</></term>
<listitem> <listitem>
<para> <para>
The identity (transaction ID) of the deleting transaction, The identity (transaction ID) of the deleting transaction,
...@@ -696,7 +698,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -696,7 +698,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>cmax</term> <term><structfield>cmax</></term>
<listitem> <listitem>
<para> <para>
The command identifier within the deleting transaction, or zero. The command identifier within the deleting transaction, or zero.
...@@ -705,16 +707,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -705,16 +707,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>ctid</term> <term><structfield>ctid</></term>
<listitem> <listitem>
<para> <para>
The tuple ID of the tuple within its table. This is a pair The tuple ID of the tuple within its table. This is a pair
(block number, tuple index within block) that identifies the (block number, tuple index within block) that identifies the
physical location of the tuple. Note that although the ctid physical location of the tuple. Note that although the <structfield>ctid</structfield>
can be used to locate the tuple very quickly, a row's ctid can be used to locate the tuple very quickly, a row's <structfield>ctid</structfield>
will change each time it is updated or moved by <command>VACUUM will change each time it is updated or moved by <command>VACUUM
FULL</>. FULL</>.
Therefore ctid is useless as a long-term row identifier. Therefore <structfield>ctid</structfield> is useless as a long-term row identifier.
The OID, or even better a user-defined serial number, should The OID, or even better a user-defined serial number, should
be used to identify logical rows. be used to identify logical rows.
</para> </para>
...@@ -731,9 +733,9 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> ) ...@@ -731,9 +733,9 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
Recommended practice when using OIDs for row identification is to create Recommended practice when using OIDs for row identification is to create
a unique index on the OID column of each table for which the OID will be 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 used. Never assume that OIDs are unique across tables; use the
combination of tableoid and row OID if you need a database-wide 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 Postgres are likely to use a separate
OID counter for each table, so that tableoid <emphasis>must</> be OID counter for each table, so that <structfield>tableoid</> <emphasis>must</> be
included to arrive at a globally unique identifier.) included to arrive at a globally unique identifier.)
</para> </para>
......
...@@ -150,8 +150,8 @@ extended user-defined types to use these same features transparently. ...@@ -150,8 +150,8 @@ extended user-defined types to use these same features transparently.
<para> <para>
An additional heuristic is provided in the parser to allow better guesses An additional heuristic is provided in the parser to allow better guesses
at proper behavior for <acronym>SQL</acronym> standard types. There are at proper behavior for <acronym>SQL</acronym> standard types. There are
several basic <firstterm>type categories</firstterm> defined: boolean, several basic <firstterm>type categories</firstterm> defined: <type>boolean</type>,
numeric, string, bitstring, datetime, timespan, geometric, network, <type>numeric</type>, <type>string</type>, <type>bitstring</type>, <type>datetime</type>, <type>timespan</type>, <type>geometric</type>, <type>network</type>,
and user-defined. Each category, with the exception of user-defined, has and user-defined. Each category, with the exception of user-defined, has
a <firstterm>preferred type</firstterm> which is preferentially selected a <firstterm>preferred type</firstterm> which is preferentially selected
when there is ambiguity. when there is ambiguity.
...@@ -273,7 +273,7 @@ If only one candidate remains, use it; else continue to the next step. ...@@ -273,7 +273,7 @@ If only one candidate remains, use it; else continue to the next step.
</step> </step>
<step performance="required"> <step performance="required">
<para> <para>
If any input arguments are "unknown", check the type categories accepted If any input arguments are <quote>unknown</quote>, check the type categories accepted
at those argument positions by the remaining candidates. At each position, at those argument positions by the remaining candidates. At each position,
select "string" select "string"
category if any candidate accepts that category (this bias towards string category if any candidate accepts that category (this bias towards string
...@@ -281,7 +281,7 @@ is appropriate since an unknown-type literal does look like a string). ...@@ -281,7 +281,7 @@ is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category, Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because select that category; otherwise fail because
the correct choice cannot be deduced without more clues. Also note whether the correct choice cannot be deduced without more clues. Also note whether
any of the candidates accept a preferred datatype within the selected category. any of the candidates accept a preferred data type within the selected category.
Now discard operator candidates that do not accept the selected type category; Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that position, discard candidates that accept non-preferred types for that
...@@ -391,7 +391,7 @@ tgl=> SELECT 'abc' || 'def' AS "Unspecified"; ...@@ -391,7 +391,7 @@ tgl=> SELECT 'abc' || 'def' AS "Unspecified";
In this case there is no initial hint for which type to use, since no types In this case there is no initial hint for which type to use, since no types
are specified in the query. So, the parser looks for all candidate operators are specified in the query. So, the parser looks for all candidate operators
and finds that there are candidates accepting both string-category and and finds that there are candidates accepting both string-category and
bitstring-category inputs. Since string category is preferred when available, bit-string-category inputs. Since string category is preferred when available,
that category is selected, and then the that category is selected, and then the
"preferred type" for strings, <type>text</type>, is used as the specific "preferred type" for strings, <type>text</type>, is used as the specific
type to resolve the unknown literals to. type to resolve the unknown literals to.
...@@ -440,7 +440,7 @@ will try to oblige. ...@@ -440,7 +440,7 @@ will try to oblige.
<step performance="required"> <step performance="required">
<para> <para>
Check for an exact match in the pg_proc system catalog. Check for an exact match in the <classname>pg_proc</classname> system catalog.
(Cases involving <type>unknown</type> will never find a match at (Cases involving <type>unknown</type> will never find a match at
this step.) this step.)
</para></step> </para></step>
...@@ -491,7 +491,7 @@ is appropriate since an unknown-type literal does look like a string). ...@@ -491,7 +491,7 @@ is appropriate since an unknown-type literal does look like a string).
Otherwise, if all the remaining candidates accept the same type category, Otherwise, if all the remaining candidates accept the same type category,
select that category; otherwise fail because select that category; otherwise fail because
the correct choice cannot be deduced without more clues. Also note whether the correct choice cannot be deduced without more clues. Also note whether
any of the candidates accept a preferred datatype within the selected category. any of the candidates accept a preferred data type within the selected category.
Now discard operator candidates that do not accept the selected type category; Now discard operator candidates that do not accept the selected type category;
furthermore, if any candidate accepts a preferred type at a given argument furthermore, if any candidate accepts a preferred type at a given argument
position, discard candidates that accept non-preferred types for that position, discard candidates that accept non-preferred types for that
...@@ -512,10 +512,10 @@ then fail. ...@@ -512,10 +512,10 @@ then fail.
If no best match could be identified, see whether the function call appears If no best match could be identified, see whether the function call appears
to be a trivial type coercion request. This happens if the function call to be a trivial type coercion request. This happens if the function call
has just one argument and the function name is the same as the (internal) has just one argument and the function name is the same as the (internal)
name of some datatype. Furthermore, the function argument must be either name of some data type. Furthermore, the function argument must be either
an unknown-type literal or a type that is binary-compatible with the named an unknown-type literal or a type that is binary-compatible with the named
datatype. When these conditions are met, the function argument is coerced data type. When these conditions are met, the function argument is coerced
to the named datatype. to the named data type.
</para> </para>
</step> </step>
</procedure> </procedure>
...@@ -527,7 +527,7 @@ to the named datatype. ...@@ -527,7 +527,7 @@ to the named datatype.
<title>Factorial Function</title> <title>Factorial Function</title>
<para> <para>
There is only one factorial function defined in the pg_proc catalog. There is only one factorial function defined in the <classname>pg_proc</classname> catalog.
So the following query automatically converts the <type>int2</type> argument So the following query automatically converts the <type>int2</type> argument
to <type>int4</type>: to <type>int4</type>:
...@@ -554,7 +554,7 @@ tgl=> select int4fac(int4(int2 '4')); ...@@ -554,7 +554,7 @@ tgl=> select int4fac(int4(int2 '4'));
<title>Substring Function</title> <title>Substring Function</title>
<para> <para>
There are two <function>substr</function> functions declared in pg_proc. However, There are two <function>substr</function> functions declared in <classname>pg_proc</classname>. However,
only one takes two arguments, of types <type>text</type> and <type>int4</type>. only one takes two arguments, of types <type>text</type> and <type>int4</type>.
</para> </para>
...@@ -679,8 +679,8 @@ tgl=> SELECT * FROM vv; ...@@ -679,8 +679,8 @@ tgl=> SELECT * FROM vv;
What's really happened here is that the two unknown literals are resolved What's really happened here is that the two unknown literals are resolved
to text by default, allowing the <literal>||</literal> operator to be to text by default, allowing the <literal>||</literal> operator to be
resolved as text concatenation. Then the text result of the operator resolved as text concatenation. Then the text result of the operator
is coerced to varchar to match the target column type. (But, since the is coerced to <type>varchar</type> to match the target column type. (But, since the
parser knows that text and varchar are binary-compatible, this coercion parser knows that text and <type>varchar</type> are binary-compatible, this coercion
is implicit and does not insert any real function call.) Finally, the is implicit and does not insert any real function call.) Finally, the
sizing function <literal>varchar(varchar,int4)</literal> is found in the system sizing function <literal>varchar(varchar,int4)</literal> is found in the system
catalogs and applied to the operator's result and the stored column length. catalogs and applied to the operator's result and the stored column length.
......
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