Markup additions and spell check. (covers User's Guide)
This commit is contained in:
parent
ba708ea3dc
commit
84956e71a3
@ -1,4 +1,4 @@
|
|||||||
<!-- $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 @@
|
|||||||
|
|
||||||
<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>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.61 2001/09/04 03:17:54 momjian Exp $
|
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.62 2001/09/09 17:21:51 petere Exp $
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<chapter id="datatype">
|
<chapter id="datatype">
|
||||||
@ -361,59 +361,59 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.61 2001/09/04 03:17:54 mo
|
|||||||
|
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry>smallint</entry>
|
<entry><type>smallint</></entry>
|
||||||
<entry>2 bytes</entry>
|
<entry>2 bytes</entry>
|
||||||
<entry>Fixed-precision</entry>
|
<entry>Fixed-precision</entry>
|
||||||
<entry>-32768 to +32767</entry>
|
<entry>-32768 to +32767</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>integer</entry>
|
<entry><type>integer</></entry>
|
||||||
<entry>4 bytes</entry>
|
<entry>4 bytes</entry>
|
||||||
<entry>Usual choice for fixed-precision</entry>
|
<entry>Usual choice for fixed-precision</entry>
|
||||||
<entry>-2147483648 to +2147483647</entry>
|
<entry>-2147483648 to +2147483647</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>bigint</entry>
|
<entry><type>bigint</></entry>
|
||||||
<entry>8 bytes</entry>
|
<entry>8 bytes</entry>
|
||||||
<entry>Very large range fixed-precision</entry>
|
<entry>Very large range fixed-precision</entry>
|
||||||
<entry>about 18 decimal digits</entry>
|
<entry>about 18 decimal digits</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>decimal</entry>
|
<entry><type>decimal</></entry>
|
||||||
<entry>variable</entry>
|
<entry>variable</entry>
|
||||||
<entry>user-specified precision, exact</entry>
|
<entry>user-specified precision, exact</entry>
|
||||||
<entry>no limit</entry>
|
<entry>no limit</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>numeric</entry>
|
<entry><type>numeric</></entry>
|
||||||
<entry>variable</entry>
|
<entry>variable</entry>
|
||||||
<entry>user-specified precision, exact</entry>
|
<entry>user-specified precision, exact</entry>
|
||||||
<entry>no limit</entry>
|
<entry>no limit</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>real</entry>
|
<entry><type>real</></entry>
|
||||||
<entry>4 bytes</entry>
|
<entry>4 bytes</entry>
|
||||||
<entry>variable-precision, inexact</entry>
|
<entry>variable-precision, inexact</entry>
|
||||||
<entry>6 decimal digits precision</entry>
|
<entry>6 decimal digits precision</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>double precision</entry>
|
<entry><type>double precision</></entry>
|
||||||
<entry>8 bytes</entry>
|
<entry>8 bytes</entry>
|
||||||
<entry>variable-precision, inexact</entry>
|
<entry>variable-precision, inexact</entry>
|
||||||
<entry>15 decimal digits precision</entry>
|
<entry>15 decimal digits precision</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>serial</entry>
|
<entry><type>serial</></entry>
|
||||||
<entry>4 bytes</entry>
|
<entry>4 bytes</entry>
|
||||||
<entry>autoincrementing integer</entry>
|
<entry>autoincrementing integer</entry>
|
||||||
<entry>1 to 2147483647</entry>
|
<entry>1 to 2147483647</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>bigserial</entry>
|
<entry><type>bigserial</type></entry>
|
||||||
<entry>8 bytes</entry>
|
<entry>8 bytes</entry>
|
||||||
<entry>autoincrementing integer</entry>
|
<entry>autoincrementing integer</entry>
|
||||||
<entry>1 to 9223372036854775807</entry>
|
<entry>1 to 9223372036854775807</entry>
|
||||||
@ -557,7 +557,7 @@ NUMERIC
|
|||||||
<para>
|
<para>
|
||||||
The data types <type>real</type> and <type>double
|
The data types <type>real</type> and <type>double
|
||||||
precision</type> are inexact, variable precision numeric types.
|
precision</type> are inexact, variable precision numeric types.
|
||||||
In practice, these types are usually implementations of IEEE 754
|
In practice, these types are usually implementations of <acronym>IEEE</acronym> 754
|
||||||
binary floating point (single and double precision,
|
binary floating point (single and double precision,
|
||||||
respectively), to the extent that the underlying processor,
|
respectively), to the extent that the underlying processor,
|
||||||
operating system, and compiler support it.
|
operating system, and compiler support it.
|
||||||
@ -636,7 +636,7 @@ NUMERIC
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <type>serial</type> datatypes are not truly types, but are a
|
The <type>serial</type> data types are not truly types, but are a
|
||||||
notational convenience for setting up unique identifier columns
|
notational convenience for setting up unique identifier columns
|
||||||
in tables.
|
in tables.
|
||||||
In the current implementation, specifying
|
In the current implementation, specifying
|
||||||
@ -777,21 +777,17 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
|
|||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry>character(<replaceable>n</>), char(<replaceable>n</>)</entry>
|
<entry><type>character(<replaceable>n</>)</type>, <type>char(<replaceable>n</>)</type></entry>
|
||||||
<entry>Fixed-length blank padded</entry>
|
<entry>Fixed-length blank padded</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>character varying(<replaceable>n</>), varchar(<replaceable>n</>)</entry>
|
<entry><type>character varying(<replaceable>n</>)</type>, <type>varchar(<replaceable>n</>)</type></entry>
|
||||||
<entry>Variable-length with limit</entry>
|
<entry>Variable-length with limit</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>text</entry>
|
<entry><type>text</type></entry>
|
||||||
<entry>Variable unlimited length</entry>
|
<entry>Variable unlimited length</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
|
||||||
<entry>bytea</entry>
|
|
||||||
<entry>binary data</entry>
|
|
||||||
</row>
|
|
||||||
</tbody>
|
</tbody>
|
||||||
</tgroup>
|
</tgroup>
|
||||||
</table>
|
</table>
|
||||||
@ -839,19 +835,6 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
|
|||||||
standard, many other RDBMS packages have it as well.
|
standard, many other RDBMS packages have it as well.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
The <type>bytea</type> data type allows storage of binary data,
|
|
||||||
specifically allowing storage of NULLs which are entered as
|
|
||||||
<literal>'\\000'</>. The first backslash is interpreted by the
|
|
||||||
single quotes, and the second is recognized by <type>bytea</> and
|
|
||||||
preceeds a three digit octal value. For a similar reason, a
|
|
||||||
backslash must be entered into a field as <literal>'\\\\'</> or
|
|
||||||
<literal>'\\134'</>. You may also have to escape line feeds and
|
|
||||||
carriage return if your interface automatically translates these. It
|
|
||||||
can store values of any length. <type>Bytea</> is a non-standard
|
|
||||||
data type.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The storage requirement for data of these types is 4 bytes plus
|
The storage requirement for data of these types is 4 bytes plus
|
||||||
the actual string, and in case of <type>character</type> plus the
|
the actual string, and in case of <type>character</type> plus the
|
||||||
@ -860,7 +843,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceabl
|
|||||||
that can be stored is about 1 GB. (The maximum value that will be
|
that can be stored is about 1 GB. (The maximum value that will be
|
||||||
allowed for <replaceable>n</> in the data type declaration is
|
allowed for <replaceable>n</> in the data type declaration is
|
||||||
actually larger than that. It wouldn't be very useful to change
|
actually larger than that. It wouldn't be very useful to change
|
||||||
this because with multi-byte character encodings the number of
|
this because with multibyte character encodings the number of
|
||||||
characters and bytes can be quite different anyway.)
|
characters and bytes can be quite different anyway.)
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@ -957,6 +940,23 @@ SELECT b, char_length(b) FROM test2;
|
|||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="datatype-binary">
|
||||||
|
<title>Binary Data</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
The <type>bytea</type> data type allows storage of binary data,
|
||||||
|
specifically allowing storage of NULLs which are entered as
|
||||||
|
<literal>'\\000'</>. The first backslash is interpreted by the
|
||||||
|
single quotes, and the second is recognized by <type>bytea</> and
|
||||||
|
precedes a three digit octal value. For a similar reason, a
|
||||||
|
backslash must be entered into a field as <literal>'\\\\'</> or
|
||||||
|
<literal>'\\134'</>. You may also have to escape line feeds and
|
||||||
|
carriage return if your interface automatically translates these. It
|
||||||
|
can store values of any length. <type>Bytea</> is a non-standard
|
||||||
|
data type.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="datatype-datetime">
|
<sect1 id="datatype-datetime">
|
||||||
<title>Date/Time Types</title>
|
<title>Date/Time Types</title>
|
||||||
|
|
||||||
@ -1083,7 +1083,7 @@ SELECT b, char_length(b) FROM test2;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>date</title>
|
<title><type>date</type></title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>date</primary>
|
<primary>date</primary>
|
||||||
@ -1260,7 +1260,7 @@ SELECT b, char_length(b) FROM test2;
|
|||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>time [ without time zone ]</title>
|
<title><type>time [ without time zone ]</type></title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>time</primary>
|
<primary>time</primary>
|
||||||
@ -1328,7 +1328,7 @@ SELECT b, char_length(b) FROM test2;
|
|||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>time with time zone</title>
|
<title><type>time with time zone</type></title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This type is defined by SQL92, but the definition exhibits
|
This type is defined by SQL92, but the definition exhibits
|
||||||
@ -1382,7 +1382,7 @@ SELECT b, char_length(b) FROM test2;
|
|||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>timestamp</title>
|
<title><type>timestamp</type></title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>timestamp</primary>
|
<primary>timestamp</primary>
|
||||||
@ -1442,7 +1442,7 @@ January 8 04:05:06 1999 PST
|
|||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>interval</title>
|
<title><type>interval</type></title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>interval</primary>
|
<primary>interval</primary>
|
||||||
@ -1664,7 +1664,7 @@ January 8 04:05:06 1999 PST
|
|||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The <envar>PGDATESTYLE</envar> environment variable used by the frontend libpq
|
The <envar>PGDATESTYLE</envar> environment variable used by the frontend <application>libpq</application>
|
||||||
on session start-up.
|
on session start-up.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
@ -1753,13 +1753,13 @@ January 8 04:05:06 1999 PST
|
|||||||
<itemizedlist spacing="compact" mark="bullet">
|
<itemizedlist spacing="compact" mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The TZ environment variable is used by the backend directly
|
The <envar>TZ</envar> environment variable is used by the backend directly
|
||||||
on postmaster start-up as the default time zone.
|
on postmaster start-up as the default time zone.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The PGTZ environment variable, if set at the client, is used by libpq
|
The <envar>PGTZ</envar> environment variable, if set at the client, is used by libpq
|
||||||
to send a <command>SET TIME ZONE</command> command to the backend upon
|
to send a <command>SET TIME ZONE</command> command to the backend upon
|
||||||
connection.
|
connection.
|
||||||
</para>
|
</para>
|
||||||
@ -1796,7 +1796,7 @@ January 8 04:05:06 1999 PST
|
|||||||
<para>
|
<para>
|
||||||
If the runtime option <literal>AUSTRALIAN_TIMEZONES</literal> is set
|
If the runtime option <literal>AUSTRALIAN_TIMEZONES</literal> is set
|
||||||
then <literal>CST</literal> and <literal>EST</literal> refer to
|
then <literal>CST</literal> and <literal>EST</literal> refer to
|
||||||
Australian timezones, not American ones.
|
Australian time zones, not American ones.
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
</para>
|
</para>
|
||||||
@ -1939,49 +1939,49 @@ SELECT * FROM test1 WHERE a;
|
|||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
<row>
|
<row>
|
||||||
<entry>point</entry>
|
<entry><type>point</type></entry>
|
||||||
<entry>16 bytes</entry>
|
<entry>16 bytes</entry>
|
||||||
<entry>(x,y)</entry>
|
<entry>(x,y)</entry>
|
||||||
<entry>Point in space</entry>
|
<entry>Point in space</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>line</entry>
|
<entry><type>line</type></entry>
|
||||||
<entry>32 bytes</entry>
|
<entry>32 bytes</entry>
|
||||||
<entry>((x1,y1),(x2,y2))</entry>
|
<entry>((x1,y1),(x2,y2))</entry>
|
||||||
<entry>Infinite line</entry>
|
<entry>Infinite line</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>lseg</entry>
|
<entry><type>lseg</type></entry>
|
||||||
<entry>32 bytes</entry>
|
<entry>32 bytes</entry>
|
||||||
<entry>((x1,y1),(x2,y2))</entry>
|
<entry>((x1,y1),(x2,y2))</entry>
|
||||||
<entry>Finite line segment</entry>
|
<entry>Finite line segment</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>box</entry>
|
<entry><type>box</type></entry>
|
||||||
<entry>32 bytes</entry>
|
<entry>32 bytes</entry>
|
||||||
<entry>((x1,y1),(x2,y2))</entry>
|
<entry>((x1,y1),(x2,y2))</entry>
|
||||||
<entry>Rectangular box</entry>
|
<entry>Rectangular box</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>path</entry>
|
<entry><type>path</type></entry>
|
||||||
<entry>4+32n bytes</entry>
|
<entry>4+32n bytes</entry>
|
||||||
<entry>((x1,y1),...)</entry>
|
<entry>((x1,y1),...)</entry>
|
||||||
<entry>Closed path (similar to polygon)</entry>
|
<entry>Closed path (similar to polygon)</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>path</entry>
|
<entry><type>path</type></entry>
|
||||||
<entry>4+32n bytes</entry>
|
<entry>4+32n bytes</entry>
|
||||||
<entry>[(x1,y1),...]</entry>
|
<entry>[(x1,y1),...]</entry>
|
||||||
<entry>Open path</entry>
|
<entry>Open path</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>polygon</entry>
|
<entry><type>polygon</type></entry>
|
||||||
<entry>4+32n bytes</entry>
|
<entry>4+32n bytes</entry>
|
||||||
<entry>((x1,y1),...)</entry>
|
<entry>((x1,y1),...)</entry>
|
||||||
<entry>Polygon (similar to closed path)</entry>
|
<entry>Polygon (similar to closed path)</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>circle</entry>
|
<entry><type>circle</type></entry>
|
||||||
<entry>24 bytes</entry>
|
<entry>24 bytes</entry>
|
||||||
<entry><(x,y),r></entry>
|
<entry><(x,y),r></entry>
|
||||||
<entry>Circle (center and radius)</entry>
|
<entry>Circle (center and radius)</entry>
|
||||||
@ -2296,21 +2296,21 @@ SELECT * FROM test1 WHERE a;
|
|||||||
<tbody>
|
<tbody>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>cidr</entry>
|
<entry><type>cidr</type></entry>
|
||||||
<entry>12 bytes</entry>
|
<entry>12 bytes</entry>
|
||||||
<entry>IP networks</entry>
|
<entry>IP networks</entry>
|
||||||
<entry>valid IPv4 networks</entry>
|
<entry>valid IPv4 networks</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>inet</entry>
|
<entry><type>inet</type></entry>
|
||||||
<entry>12 bytes</entry>
|
<entry>12 bytes</entry>
|
||||||
<entry>IP hosts and networks</entry>
|
<entry>IP hosts and networks</entry>
|
||||||
<entry>valid IPv4 hosts or networks</entry>
|
<entry>valid IPv4 hosts or networks</entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<row>
|
<row>
|
||||||
<entry>macaddr</entry>
|
<entry><type>macaddr</type></entry>
|
||||||
<entry>6 bytes</entry>
|
<entry>6 bytes</entry>
|
||||||
<entry>MAC addresses</entry>
|
<entry>MAC addresses</entry>
|
||||||
<entry>customary formats</entry>
|
<entry>customary formats</entry>
|
||||||
@ -2386,9 +2386,9 @@ SELECT * FROM test1 WHERE a;
|
|||||||
<tgroup cols="3">
|
<tgroup cols="3">
|
||||||
<thead>
|
<thead>
|
||||||
<row>
|
<row>
|
||||||
<entry>CIDR Input</entry>
|
<entry><type>CIDR</type> Input</entry>
|
||||||
<entry>CIDR Displayed</entry>
|
<entry><type>CIDR</type> Displayed</entry>
|
||||||
<entry>abbrev(CIDR)</entry>
|
<entry><function>abbrev</function>(<type>CIDR</type>)</entry>
|
||||||
</row>
|
</row>
|
||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
<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>
|
||||||
|
File diff suppressed because it is too large
Load Diff
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
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
|
|||||||
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
|
|||||||
<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
|
|||||||
<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.
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $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
|
|||||||
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
|
|||||||
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,
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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 (
|
|||||||
|
|
||||||
<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
|
|||||||
<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>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
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>
|
||||||
|
|
||||||
|
@ -1,17 +1,15 @@
|
|||||||
<!--
|
<!--
|
||||||
$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.
|
|||||||
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.
|
|||||||
<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.
|
|||||||
</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=>
|
|||||||
</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
|
|||||||
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
|
|||||||
</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
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
<variablelist>
|
<variablelist>
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>
|
<term>
|
||||||
GiST and R-Tree indexes
|
<acronym>GiST</acronym> and R-Tree indexes
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
|
|
||||||
<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>=></literal></quote>
|
<quote><literal>=></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
|
|||||||
<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>.
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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)
|
|||||||
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)
|
|||||||
|
|
||||||
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:
|
|||||||
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)
|
|||||||
</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 < 50" WHERE clause at that node.
|
because we are applying the "unique1 < 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)
|
|||||||
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 < t2.hundred",
|
For example, if we added "WHERE ... AND t1.hundred < 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)
|
|||||||
(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;
|
|||||||
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.
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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
|
|||||||
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
|
|||||||
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
|
|||||||
<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
|
|||||||
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>
|
||||||
|
@ -1,4 +1,4 @@
|
|||||||
<!-- $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
|
|||||||
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
|
|||||||
</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
|
|||||||
|
|
||||||
<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
|
|||||||
<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 > 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
|
|||||||
</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
|
|||||||
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;
|
|||||||
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><</literal> operator. Similarly,
|
in terms of the <literal><</literal> operator. Similarly,
|
||||||
descending order is determined with the <literal>></literal>
|
descending order is determined with the <literal>></literal>
|
||||||
|
@ -1,5 +1,5 @@
|
|||||||
<!--
|
<!--
|
||||||
$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> )
|
|||||||
<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> )
|
|||||||
|
|
||||||
<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>
|
||||||
~ ! @ # % ^ & | ` ? $
|
~ ! @ # % ^ & | ` ? $
|
||||||
@ -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> )
|
|||||||
|
|
||||||
<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> )
|
|||||||
</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> )
|
|||||||
</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> )
|
|||||||
</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> )
|
|||||||
</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> )
|
|||||||
</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> )
|
|||||||
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.
|
|||||||
<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.
|
|||||||
</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).
|
|||||||
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";
|
|||||||
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.
|
|||||||
|
|
||||||
<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).
|
|||||||
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.
|
|||||||
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.
|
|||||||
<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'));
|
|||||||
<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;
|
|||||||
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.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user