mirror of
https://github.com/postgres/postgres.git
synced 2025-07-07 00:36:50 +03:00
Add more appropriate markup.
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.21 2002/08/05 19:43:30 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.22 2002/09/21 18:32:52 petere Exp $ -->
|
||||
|
||||
<sect1 id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -251,8 +251,8 @@ SELECT * FROM sal_emp WHERE pay_by_quarter **= 10000;
|
||||
<note>
|
||||
<para>
|
||||
A limitation of the present array implementation is that individual
|
||||
elements of an array cannot be SQL NULLs. The entire array can be set
|
||||
to NULL, but you can't have an array with some elements NULL and some
|
||||
elements of an array cannot be SQL null values. The entire array can be set
|
||||
to null, but you can't have an array with some elements null and some
|
||||
not. Fixing this is on the to-do list.
|
||||
</para>
|
||||
</note>
|
||||
@ -267,7 +267,7 @@ SELECT * FROM sal_emp WHERE pay_by_quarter **= 10000;
|
||||
around the array value plus delimiter characters between adjacent items.
|
||||
The delimiter character is usually a comma (<literal>,</>) but can be
|
||||
something else: it is determined by the <literal>typdelim</> setting
|
||||
for the array's element type. (Among the standard datatypes provided
|
||||
for the array's element type. (Among the standard data types provided
|
||||
in the <productname>PostgreSQL</productname> distribution, type
|
||||
<literal>box</> uses a semicolon (<literal>;</>) but all the others
|
||||
use comma.) In a multidimensional array, each dimension (row, plane,
|
||||
@ -300,8 +300,8 @@ SELECT * FROM sal_emp WHERE pay_by_quarter **= 10000;
|
||||
if they are empty strings or contain curly braces, delimiter characters,
|
||||
double quotes, backslashes, or white space. Double quotes and backslashes
|
||||
embedded in element values will be backslash-escaped. For numeric
|
||||
datatypes it is safe to assume that double quotes will never appear, but
|
||||
for textual datatypes one should be prepared to cope with either presence
|
||||
data types it is safe to assume that double quotes will never appear, but
|
||||
for textual data types one should be prepared to cope with either presence
|
||||
or absence of quotes. (This is a change in behavior from pre-7.2
|
||||
<productname>PostgreSQL</productname> releases.)
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.28 2002/09/18 20:09:31 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.29 2002/09/21 18:32:52 petere Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
@ -405,27 +405,27 @@ perl: warning: Falling back to the standard locale ("C").
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN1</literal></entry>
|
||||
<entry>ISO 8859-1 ECMA-94 Latin Alphabet No.1</entry>
|
||||
<entry>ISO 8859-1 <acronym>ECMA</>-94 Latin Alphabet No.1</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN2</literal></entry>
|
||||
<entry>ISO 8859-2 ECMA-94 Latin Alphabet No.2</entry>
|
||||
<entry>ISO 8859-2 <acronym>ECMA</>-94 Latin Alphabet No.2</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN3</literal></entry>
|
||||
<entry>ISO 8859-3 ECMA-94 Latin Alphabet No.3</entry>
|
||||
<entry>ISO 8859-3 <acronym>ECMA</>-94 Latin Alphabet No.3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN4</literal></entry>
|
||||
<entry>ISO 8859-4 ECMA-94 Latin Alphabet No.4</entry>
|
||||
<entry>ISO 8859-4 <acronym>ECMA</>-94 Latin Alphabet No.4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN5</literal></entry>
|
||||
<entry>ISO 8859-9 ECMA-128 Latin Alphabet No.5</entry>
|
||||
<entry>ISO 8859-9 <acronym>ECMA</>-128 Latin Alphabet No.5</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN6</literal></entry>
|
||||
<entry>ISO 8859-10 ECMA-144 Latin Alphabet No.6</entry>
|
||||
<entry>ISO 8859-10 <acronym>ECMA</>-144 Latin Alphabet No.6</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN7</literal></entry>
|
||||
@ -441,23 +441,23 @@ perl: warning: Falling back to the standard locale ("C").
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>LATIN10</literal></entry>
|
||||
<entry>ISO 8859-16 ASRO SR 14111 Latin Alphabet No.10</entry>
|
||||
<entry>ISO 8859-16 <acronym>ASRO</> SR 14111 Latin Alphabet No.10</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>ISO-8859-5</literal></entry>
|
||||
<entry>ECMA-113 Latin/Cyrillic</entry>
|
||||
<entry><acronym>ECMA</>-113 Latin/Cyrillic</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>ISO-8859-6</literal></entry>
|
||||
<entry>ECMA-114 Latin/Arabic</entry>
|
||||
<entry><acronym>ECMA</>-114 Latin/Arabic</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>ISO-8859-7</literal></entry>
|
||||
<entry>ECMA-118 Latin/Greek</entry>
|
||||
<entry><acronym>ECMA</>-118 Latin/Greek</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>ISO-8859-8</literal></entry>
|
||||
<entry>ECMA-121 Latin/Hebrew</entry>
|
||||
<entry><acronym>ECMA</>-121 Latin/Hebrew</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>KOI8</literal></entry>
|
||||
@ -477,7 +477,7 @@ perl: warning: Falling back to the standard locale ("C").
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>TCVN</literal></entry>
|
||||
<entry>Vietnamese TCVN-5712(Windows CP1258)</entry>
|
||||
<entry>Vietnamese <acronym>TCVN</>-5712 (Windows CP1258)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>WIN874</literal></entry>
|
||||
@ -500,7 +500,7 @@ perl: warning: Falling back to the standard locale ("C").
|
||||
|
||||
<important>
|
||||
<para>
|
||||
Not all APIs supports all the encodings listed above. For example, the
|
||||
Not all <acronym>API</>s supports all the encodings listed above. For example, the
|
||||
<productname>PostgreSQL</>
|
||||
JDBC driver does not support <literal>MULE_INTERNAL</>, <literal>LATIN6</>,
|
||||
<literal>LATIN8</>, and <literal>LATIN10</>.
|
||||
@ -572,7 +572,7 @@ $ <userinput>psql -l</userinput>
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> supports an automatic
|
||||
encoding conversion between server and client for some
|
||||
encodings. The conversion info is stored in pg_converson system
|
||||
encodings. The conversion info is stored in <literal>pg_conversion</> system
|
||||
catalog. You can create a new conversion by using <command>CREATE
|
||||
CONVERSION</command>. PostgreSQL comes with some predefined
|
||||
conversions. They are listed in <xref
|
||||
@ -878,7 +878,7 @@ RESET CLIENT_ENCODING;
|
||||
<para>
|
||||
Using client_encoding variable.
|
||||
|
||||
If client_encoding variable in postgresql.conf is set, that
|
||||
If the <varname>client_encoding</> variable in <filename>postgresql.conf</> is set, that
|
||||
client encoding is automatically selected when a connection to the
|
||||
server is made. (This can subsequently be overridden using any of the
|
||||
other methods mentioned above.)
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.38 2002/09/18 20:09:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.39 2002/09/21 18:32:52 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
@ -261,7 +261,7 @@ hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <
|
||||
<term><literal>password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Same as "md5", but the password is sent in cleartext over the
|
||||
Same as "md5", but the password is sent in clear text over the
|
||||
network. This should not be used on untrusted networks.
|
||||
See <xref linkend="auth-password"> for details.
|
||||
</para>
|
||||
@ -314,8 +314,10 @@ hostssl <replaceable>database</replaceable> <replaceable>user</replaceable> <
|
||||
|
||||
<para>
|
||||
For local connections, this only works on machines that
|
||||
support Unix-domain socket credentials (currently Linux,
|
||||
FreeBSD, NetBSD, and BSD/OS).
|
||||
support Unix-domain socket credentials (currently
|
||||
<systemitem class=osname>Linux</>, <systemitem
|
||||
class=osname>FreeBSD</>, <systemitem class=osname>NetBSD</>,
|
||||
and <systemitem class=osname>BSD/OS</>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -504,7 +506,7 @@ local db1,db2,@demodbs all md5
|
||||
if you trust every user on every machine that is allowed to connect
|
||||
to the postmaster by the <filename>pg_hba.conf</> lines that specify
|
||||
<literal>trust</>. It is seldom reasonable to use <literal>trust</>
|
||||
for any TCP connections other than those from localhost (127.0.0.1).
|
||||
for any TCP connections other than those from <systemitem>localhost</> (127.0.0.1).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.103 2002/09/18 21:35:20 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.104 2002/09/21 18:32:52 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
@ -703,7 +703,7 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> (
|
||||
implied <literal>UNIQUE</literal>. This is no longer automatic. If
|
||||
you wish a serial column to be <literal>UNIQUE</literal> or a
|
||||
<literal>PRIMARY KEY</literal> it must now be specified, same as with
|
||||
any other datatype.
|
||||
any other data type.
|
||||
</para></note>
|
||||
</sect2>
|
||||
</sect1>
|
||||
@ -2028,7 +2028,7 @@ January 8 04:05:06 1999 PST
|
||||
<listitem>
|
||||
<para>
|
||||
The default time zone is specified as a constant integer offset
|
||||
from GMT/UTC. It is not possible to adapt to daylight-saving
|
||||
from <acronym>GMT</>/<acronym>UTC</>. It is not possible to adapt to daylight-saving
|
||||
time when doing date/time arithmetic across
|
||||
<acronym>DST</acronym> boundaries.
|
||||
</para>
|
||||
@ -3025,14 +3025,14 @@ SELECT * FROM test;
|
||||
|
||||
<row>
|
||||
<entry><type>regproc</></entry>
|
||||
<entry>pg_proc</entry>
|
||||
<entry><structname>pg_proc</></entry>
|
||||
<entry>Function name</entry>
|
||||
<entry>sum</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>regprocedure</></entry>
|
||||
<entry>pg_proc</entry>
|
||||
<entry><structname>pg_proc</></entry>
|
||||
<entry>Function with argument types</entry>
|
||||
<entry>sum(int4)</entry>
|
||||
</row>
|
||||
@ -3098,7 +3098,7 @@ SELECT * FROM test;
|
||||
|
||||
<para>
|
||||
Another identifier type used by the system is <type>xid</>, or transaction
|
||||
(abbreviated xact) identifier. This is the datatype of the system columns
|
||||
(abbreviated <abbrev>xact</>) identifier. This is the data type of the system columns
|
||||
<structfield>xmin</> and <structfield>xmax</>.
|
||||
Transaction identifiers are 32-bit quantities. In a long-lived
|
||||
database it is possible for transaction IDs to wrap around. This
|
||||
@ -3110,7 +3110,7 @@ SELECT * FROM test;
|
||||
|
||||
<para>
|
||||
A third identifier type used by the system is <type>cid</>, or command
|
||||
identifier. This is the datatype of the system columns
|
||||
identifier. This is the data type of the system columns
|
||||
<structfield>cmin</> and <structfield>cmax</>.
|
||||
Command identifiers are also 32-bit quantities. This creates a hard
|
||||
limit of 2<superscript>32</> (4 billion) SQL commands within a single
|
||||
@ -3121,7 +3121,7 @@ SELECT * FROM test;
|
||||
|
||||
<para>
|
||||
A final identifier type used by the system is <type>tid</>, or tuple
|
||||
identifier. This is the datatype of the system column
|
||||
identifier. This is the data type of the system column
|
||||
<structfield>ctid</>. A tuple ID is a pair
|
||||
(block number, tuple index within block) that identifies the
|
||||
physical location of the tuple within its table.
|
||||
@ -3172,10 +3172,10 @@ SELECT * FROM test;
|
||||
The <productname>PostgreSQL</productname> type system contains a number
|
||||
of special-purpose entries that are collectively called
|
||||
<firstterm>pseudo-types</>. A pseudo-type cannot be used as a column
|
||||
datatype, but it can be used to declare a function's argument or result
|
||||
data type, but it can be used to declare a function's argument or result
|
||||
type. Each of the available pseudo-types is useful in situations where
|
||||
a function's behavior does not correspond to simply taking or returning
|
||||
a value of a specific SQL datatype.
|
||||
a value of a specific SQL data type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -3198,12 +3198,12 @@ SELECT * FROM test;
|
||||
|
||||
<row>
|
||||
<entry><type>any</></entry>
|
||||
<entry>Indicates that a function accepts any input datatype whatever</entry>
|
||||
<entry>Indicates that a function accepts any input data type whatever</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><type>anyarray</></entry>
|
||||
<entry>Indicates that a function accepts any array datatype</entry>
|
||||
<entry>Indicates that a function accepts any array data type</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -3243,7 +3243,7 @@ SELECT * FROM test;
|
||||
|
||||
<para>
|
||||
Functions coded in C (whether built-in or dynamically loaded) may be
|
||||
declared to accept or return any of these pseudo datatypes. It is up to
|
||||
declared to accept or return any of these pseudo data types. It is up to
|
||||
the function author to ensure that the function will behave safely
|
||||
when a pseudo-type is used as an argument type.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.4 2002/09/12 22:05:35 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -765,7 +765,7 @@ CREATE TABLE order_items (
|
||||
Note that these do not excuse you from observing any constraints.
|
||||
For example, if an action specifies <literal>SET DEFAULT</literal>
|
||||
but the default value would not satisfy the foreign key, the
|
||||
deletion of the primary key wil fail.
|
||||
deletion of the primary key will fail.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1425,7 +1425,7 @@ SHOW search_path;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The first schema in the seach path that exists is the default
|
||||
The first schema in the search path that exists is the default
|
||||
location for creating new objects. That is the reason that by
|
||||
default objects are created in the public schema. When objects
|
||||
are referenced in any other context without schema qualification
|
||||
@ -1466,8 +1466,8 @@ SET search_path TO myschema;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The search path works in the same way for datatype names, function names,
|
||||
and operator names as it does for table names. Datatype and function
|
||||
The search path works in the same way for data type names, function names,
|
||||
and operator names as it does for table names. Data type and function
|
||||
names can be qualified in exactly the same way as table names. If you
|
||||
need to write a qualified operator name in an expression, there is a
|
||||
special provision: you must write
|
||||
@ -1519,7 +1519,7 @@ REVOKE CREATE ON public FROM PUBLIC;
|
||||
<para>
|
||||
In addition to <literal>public</> and user-created schemas, each
|
||||
database contains a <literal>pg_catalog</> schema, which contains
|
||||
the system tables and all the built-in datatypes, functions, and
|
||||
the system tables and all the built-in data types, functions, and
|
||||
operators. <literal>pg_catalog</> is always effectively part of
|
||||
the search path. If it is not named explicitly in the path then
|
||||
it is implicitly searched <emphasis>before</> searching the path's
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/Attic/developer.sgml,v 1.6 2001/10/09 18:45:59 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/Attic/developer.sgml,v 1.7 2002/09/21 18:32:52 petere Exp $ -->
|
||||
<!-- PostgreSQL Developer's Guide -->
|
||||
|
||||
<book id="developer">
|
||||
@ -24,6 +24,7 @@
|
||||
&bki;
|
||||
&page;
|
||||
&geqo;
|
||||
&gist;
|
||||
&nls;
|
||||
<!-- appendices -->
|
||||
&cvs;
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.21 2002/08/26 23:22:47 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.22 2002/09/21 18:32:52 petere Exp $
|
||||
-->
|
||||
|
||||
<sect2 id="dfunc">
|
||||
@ -58,7 +58,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.21 2002/08/26 23:22:47 momji
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><productname>BSD/OS</productname></term>
|
||||
<term><systemitem class="osname">BSD/OS</></term>
|
||||
<indexterm><primary>BSD/OS</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -70,13 +70,13 @@ gcc -fpic -c foo.c
|
||||
ld -shared -o foo.so foo.o
|
||||
</programlisting>
|
||||
This is applicable as of version 4.0 of
|
||||
<productname>BSD/OS</productname>.
|
||||
<systemitem class="osname">BSD/OS</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>FreeBSD</productname></term>
|
||||
<term><systemitem class="osname">FreeBSD</></term>
|
||||
<indexterm><primary>FreeBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -88,19 +88,19 @@ gcc -fpic -c foo.c
|
||||
gcc -shared -o foo.so foo.o
|
||||
</programlisting>
|
||||
This is applicable as of version 3.0 of
|
||||
<productname>FreeBSD</productname>.
|
||||
<systemitem class="osname">FreeBSD</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>HP-UX</productname></term>
|
||||
<term><systemitem class="osname">HP-UX</></term>
|
||||
<indexterm><primary>HP-UX</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag of the system compiler to create
|
||||
<acronym>PIC</acronym> is <option>+z</option>. When using
|
||||
<productname>GCC</productname> it's <option>-fpic</option>. The
|
||||
<application>GCC</application> it's <option>-fpic</option>. The
|
||||
linker flag for shared libraries is <option>-b</option>. So
|
||||
<programlisting>
|
||||
cc +z -c foo.c
|
||||
@ -113,7 +113,7 @@ gcc -fpic -c foo.c
|
||||
<programlisting>
|
||||
ld -b -o foo.sl foo.o
|
||||
</programlisting>
|
||||
<productname>HP-UX</productname> uses the extension
|
||||
<systemitem class="osname">HP-UX</> uses the extension
|
||||
<filename>.sl</filename> for shared libraries, unlike most other
|
||||
systems.
|
||||
</para>
|
||||
@ -121,7 +121,7 @@ ld -b -o foo.sl foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>IRIX</productname></term>
|
||||
<term><systemitem class="osname">IRIX</></term>
|
||||
<indexterm><primary>IRIX</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -137,7 +137,7 @@ ld -shared -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Linux</productname></term>
|
||||
<term><systemitem class="osname">Linux</></term>
|
||||
<indexterm><primary>Linux</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -156,7 +156,21 @@ cc -shared -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>NetBSD</productname></term>
|
||||
<term><systemitem class="osname">MacOS X</></term>
|
||||
<indexterm><primary>MacOS X</></>
|
||||
<listitem>
|
||||
<para>
|
||||
Here is a sample. It assumes the developer tools are installed.
|
||||
<programlisting>
|
||||
cc -c foo.c
|
||||
cc -bundle -flat_namespace -undefined suppress -o foo.so foo.o
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">NetBSD</></term>
|
||||
<indexterm><primary>NetBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -174,7 +188,7 @@ gcc -shared -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>OpenBSD</productname></term>
|
||||
<term><systemitem class="osname">OpenBSD</></term>
|
||||
<indexterm><primary>OpenBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -190,30 +204,16 @@ ld -Bshareable -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>OS X</productname></term>
|
||||
<indexterm><primary>OS X</></>
|
||||
<listitem>
|
||||
<para>
|
||||
Here is a sample. It assumes the developer tools are installed.
|
||||
<programlisting>
|
||||
cc -c foo.c
|
||||
cc -bundle -flat_namespace -undefined suppress -o foo.so foo.o
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Solaris</productname></term>
|
||||
<term><systemitem class="osname">Solaris</></term>
|
||||
<indexterm><primary>Solaris</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
<option>-KPIC</option> with the Sun compiler and
|
||||
<option>-fpic</option> with <productname>GCC</productname>. To
|
||||
<option>-fpic</option> with <application>GCC</>. To
|
||||
link shared libraries, the compiler option is
|
||||
<option>-G</option> with either compiler or alternatively
|
||||
<option>-shared</option> with <productname>GCC</productname>.
|
||||
<option>-shared</option> with <application>GCC</>.
|
||||
<programlisting>
|
||||
cc -KPIC -c foo.c
|
||||
cc -G -o foo.so foo.o
|
||||
@ -228,7 +228,7 @@ gcc -G -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Tru64 UNIX</term>
|
||||
<term><systemitem class="osname">Tru64 UNIX</></term>
|
||||
<indexterm><primary>Tru64 UNIX</></>
|
||||
<indexterm><primary>Digital UNIX</><see>Tru64 UNIX</></>
|
||||
<listitem>
|
||||
@ -247,7 +247,7 @@ ld -shared -expect_unresolved '*' -o foo.so foo.o
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>UnixWare</productname></term>
|
||||
<term><systemitem class="osname">UnixWare</></term>
|
||||
<indexterm><primary>UnixWare</></>
|
||||
<listitem>
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.4 2002/07/05 00:14:16 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.5 2002/09/21 18:32:52 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="diskusage">
|
||||
@ -16,7 +16,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.4 2002/07/05 00:14:16 mo
|
||||
Each table has a primary heap disk file where most of the data is
|
||||
stored. To store long column values, there is also a
|
||||
<acronym>TOAST</> file associated with the table, named based on the
|
||||
table's oid (actually pg_class.relfilenode), and an index on the
|
||||
table's OID (actually <literal>pg_class.relfilenode</>), and an index on the
|
||||
<acronym>TOAST</> table. There also may be indexes associated with
|
||||
the base table.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.36 2002/01/20 22:19:55 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.37 2002/09/21 18:32:52 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="ecpg">
|
||||
@ -158,8 +158,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.36 2002/01/20 22:19:55 petere
|
||||
<programlisting>
|
||||
exec sql include sqlca;
|
||||
</programlisting>
|
||||
in the include section of your file. This will define a struct and
|
||||
a variable with the name <parameter>sqlca</parameter> as follows:
|
||||
in the include section of your file. This will define a <type>struct</> and
|
||||
a variable with the name <varname>sqlca</varname> as follows:
|
||||
<programlisting>
|
||||
struct sqlca
|
||||
{
|
||||
@ -198,7 +198,7 @@ struct sqlca
|
||||
|
||||
<para>
|
||||
If an no error occurred in the last <acronym>SQL</acronym> statement.
|
||||
<parameter>sqlca.sqlcode</parameter> will be 0 (ECPG_NO_ERROR). If
|
||||
<parameter>sqlca.sqlcode</parameter> will be 0 (<symbol>ECPG_NO_ERROR</>). If
|
||||
<parameter>sqlca.sqlcode</parameter> is less that zero, this is a
|
||||
serious error, like the database definition does not match the
|
||||
query. If it is greater than zero, it is a normal error like the
|
||||
@ -620,8 +620,9 @@ exec sql end declare section;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The special types <type>VARCHAR</type> and <type>VARCHAR2</type> are converted into a named struct
|
||||
for every variable. A declaration like:
|
||||
The special types <type>VARCHAR</type> and
|
||||
<type>VARCHAR2</type> are converted into a named <type>struct</> for
|
||||
every variable. A declaration like:
|
||||
<programlisting>
|
||||
VARCHAR var[180];
|
||||
</programlisting>
|
||||
@ -1023,10 +1024,10 @@ ECPGdo(__LINE__, NULL, "select res from mytable where index = ? ",
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>ECPGt_EOIT</literal></term>
|
||||
<term><parameter>ECPGt_EOIT</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
An enum telling that there are no more input variables.
|
||||
An <type>enum</> telling that there are no more input variables.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1042,10 +1043,10 @@ ECPGdo(__LINE__, NULL, "select res from mytable where index = ? ",
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>ECPGt_EORT</term>
|
||||
<term><parameter>ECPGt_EORT</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
An enum telling that there are no more variables.
|
||||
An <type>enum</> telling that there are no more variables.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.16 2002/07/30 17:34:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.17 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="extend">
|
||||
@ -135,51 +135,51 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.16 2002/07/30 17:34:37 tgl
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>pg_database</entry>
|
||||
<entry><structname>pg_database</></entry>
|
||||
<entry> databases</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_class</entry>
|
||||
<entry><structname>pg_class</></entry>
|
||||
<entry> tables</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_attribute</entry>
|
||||
<entry><structname>pg_attribute</></entry>
|
||||
<entry> table columns</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_index</entry>
|
||||
<entry><structname>pg_index</></entry>
|
||||
<entry> indexes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_proc</entry>
|
||||
<entry><structname>pg_proc</></entry>
|
||||
<entry> procedures/functions </entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_type</entry>
|
||||
<entry><structname>pg_type</></entry>
|
||||
<entry> data types (both base and complex)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_operator</entry>
|
||||
<entry><structname>pg_operator</></entry>
|
||||
<entry> operators</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_aggregate</entry>
|
||||
<entry><structname>pg_aggregate</></entry>
|
||||
<entry> aggregate functions</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_am</entry>
|
||||
<entry><structname>pg_am</></entry>
|
||||
<entry> access methods</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_amop</entry>
|
||||
<entry><structname>pg_amop</></entry>
|
||||
<entry> access method operators</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_amproc</entry>
|
||||
<entry><structname>pg_amproc</></entry>
|
||||
<entry> access method support functions</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_opclass</entry>
|
||||
<entry><structname>pg_opclass</></entry>
|
||||
<entry> access method operator classes</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.6 2002/08/04 06:17:29 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.7 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="features">
|
||||
@ -1089,12 +1089,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/features.sgml,v 2.6 2002/08/04 06:17:29 tho
|
||||
</row>
|
||||
<row>
|
||||
<entry>F831-01</entry>
|
||||
<entry>Updateable scrollable cursors</entry>
|
||||
<entry>Updatable scrollable cursors</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>F831-02</entry>
|
||||
<entry>Updateable ordered cursors</entry>
|
||||
<entry>Updatable ordered cursors</entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
|
File diff suppressed because it is too large
Load Diff
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.36 2002/08/13 20:40:43 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.37 2002/09/21 18:32:53 petere Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indexes</title>
|
||||
@ -182,7 +182,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
<note>
|
||||
<para>
|
||||
Testing has shown PostgreSQL's hash indexes to be similar or slower
|
||||
than btree indexes, and the index size and build time for hash
|
||||
than B-tree indexes, and the index size and build time for hash
|
||||
indexes is much worse. Hash indexes also suffer poor performance
|
||||
under high concurrency. For these reasons, hash index use is
|
||||
discouraged.
|
||||
@ -517,7 +517,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Should not allow NULLs.
|
||||
Should not allow null values.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -540,7 +540,7 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
NULLs are acceptable.
|
||||
Null values are acceptable.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.81 2002/09/18 20:09:31 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.82 2002/09/21 18:32:53 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -146,7 +146,7 @@ su - postgres
|
||||
*** You might have to rebuild your Perl installation. Refer to
|
||||
*** the documentation for details.
|
||||
</screen>
|
||||
(If you don't follow the onscreen output you will merely notice
|
||||
(If you don't follow the on-screen output you will merely notice
|
||||
the the PL/Perl library object will not be installed.) If you
|
||||
see this, you will have to re-build and install
|
||||
<productname>Perl</productname> manually to be able to build
|
||||
@ -239,7 +239,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<para>
|
||||
To enable Native Language Support (<acronym>NLS</acronym>), that
|
||||
is, the ability to display a program's messages in a language
|
||||
other than English, you need an implementation of the Gettext
|
||||
other than English, you need an implementation of the <application>Gettext</>
|
||||
<acronym>API</acronym>. Some operating systems have this
|
||||
built-in (e.g., <systemitem class="osname">Linux</>, <systemitem
|
||||
class="osname">NetBSD</>, <systemitem
|
||||
@ -256,7 +256,8 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Kerberos, OpenSSL, or PAM, if you want to support
|
||||
<application>Kerberos</>, <application>OpenSSL</>, or <application>PAM</>,
|
||||
if you want to support
|
||||
authentication using these services.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -885,7 +886,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--without-readline</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Prevents the use of the Readline library. This disables
|
||||
Prevents the use of the <application>Readline</> library. This disables
|
||||
command-line editing and history in
|
||||
<application>psql</application>, so it is not recommended.
|
||||
</para>
|
||||
@ -896,7 +897,7 @@ JAVACMD=$JAVA_HOME/bin/java
|
||||
<term><option>--without-zlib</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Prevents the use of the Zlib library. This disables
|
||||
Prevents the use of the <application>Zlib</> library. This disables
|
||||
compression support in <application>pg_dump</application>.
|
||||
This option is only intended for those rare systems where this
|
||||
library is not available.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.37 2002/09/18 20:09:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.38 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="jdbc">
|
||||
@ -57,9 +57,9 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.37 2002/09/18 20:09:31
|
||||
instructions. After installation, the driver should be found in
|
||||
<filename><replaceable>PREFIX</>/share/java/postgresql.jar</filename>.
|
||||
The resulting driver will be built for the version of Java you are
|
||||
running. If you build with a 1.1 JDK you will build a version
|
||||
running. If you build with a 1.1 <acronym>JDK</> you will build a version
|
||||
that supports the JDBC 1 specification, if you build with a Java 2
|
||||
JDK (e.g., JDK 1.2 or JDK 1.3) you will build a version that
|
||||
<acronym>JDK</> (e.g., <acronym>JDK</> 1.2 or <acronym>JDK</> 1.3) you will build a version that
|
||||
supports the JDBC 2 specification.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -545,7 +545,7 @@ st.close();
|
||||
need to understand the limitations of each method. The
|
||||
<type>bytea</type> data type is not well suited for storing very
|
||||
large amounts of binary data. While a column of type
|
||||
<type>bytea</type> can hold upto 1Gig of binary data, it would
|
||||
<type>bytea</type> can hold up to 1 GB of binary data, it would
|
||||
require a huge amount of memory (<acronym>RAM</acronym>) to
|
||||
process such a large value. The Large Object method for
|
||||
storing binary data is better suited to storing very large values,
|
||||
@ -838,7 +838,7 @@ Fastpath fp = ((org.postgresql.Connection)myconn).getFastpathAPI();
|
||||
<formalpara>
|
||||
<title>Throws:</title>
|
||||
<para>
|
||||
SQLException by Fastpath when initializing for first time
|
||||
<classname>SQLException</> by Fastpath when initializing for first time
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
@ -1106,7 +1106,7 @@ public void addFunction(String name,
|
||||
<para>
|
||||
This adds a function to our look-up table. User code should
|
||||
use the <function>addFunctions</function> method, which is based upon a query,
|
||||
rather than hard coding the oid. The oid for a function is not
|
||||
rather than hard coding the OID. The OID for a function is not
|
||||
guaranteed to remain static, even on different servers of the
|
||||
same version.
|
||||
</para>
|
||||
@ -1118,7 +1118,7 @@ public void addFunctions(ResultSet rs) throws SQLException
|
||||
</synopsis>
|
||||
<para>
|
||||
This takes a <classname>ResultSet</classname> containing two columns. Column 1
|
||||
contains the function name, Column 2 the oid. It reads the
|
||||
contains the function name, Column 2 the OID. It reads the
|
||||
entire <classname>ResultSet</classname>, loading the values into the function table.
|
||||
</para>
|
||||
|
||||
@ -2154,21 +2154,21 @@ public int read(byte buf[],
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>buf</term>
|
||||
<term><parameter>buf</></term>
|
||||
<listitem>
|
||||
<simpara>destination array</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>off</term>
|
||||
<term><parameter>off</></term>
|
||||
<listitem>
|
||||
<simpara>offset within array</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>len</term>
|
||||
<term><parameter>len</></term>
|
||||
<listitem>
|
||||
<simpara>number of bytes to read</simpara>
|
||||
</listitem>
|
||||
@ -2202,21 +2202,21 @@ public void write(byte buf[],
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>buf</term>
|
||||
<term><parameter>buf</></term>
|
||||
<listitem>
|
||||
<simpara>destination array</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>off</term>
|
||||
<term><parameter>off</></term>
|
||||
<listitem>
|
||||
<simpara>offset within array</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>len</term>
|
||||
<term><parameter>len</></term>
|
||||
<listitem>
|
||||
<simpara>number of bytes to write</simpara>
|
||||
</listitem>
|
||||
@ -2350,21 +2350,21 @@ lobj = ((org.postgresql.Connection)myconn).getLargeObjectAPI();
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>public static final int WRITE</term>
|
||||
<term><literal>public static final int WRITE</></term>
|
||||
<listitem>
|
||||
<simpara>This mode indicates we want to write to an object.</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>public static final int READ</term>
|
||||
<term><literal>public static final int READ</></term>
|
||||
<listitem>
|
||||
<simpara>This mode indicates we want to read an object.</simpara>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>public static final int READWRITE</term>
|
||||
<term><literal>public static final int READWRITE</></term>
|
||||
<listitem>
|
||||
<simpara>This mode is the default. It indicates we want read and write access to a large object.</simpara>
|
||||
</listitem>
|
||||
@ -2382,8 +2382,8 @@ public LargeObject open(int oid) throws SQLException
|
||||
</synopsis>
|
||||
<para>
|
||||
This opens an existing large object, based on its OID. This
|
||||
method assumes that READ and WRITE access is required (the
|
||||
default).
|
||||
method assumes that <symbol>READ</> and
|
||||
<symbol>WRITE</> access is required (the default).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2404,7 +2404,7 @@ public int create() throws SQLException
|
||||
</synopsis>
|
||||
<para>
|
||||
This creates a large object, returning its OID.
|
||||
It defaults to READWRITE for the new object's attributes.
|
||||
It defaults to <symbol>READWRITE</> for the new object's attributes.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -1038,7 +1038,7 @@ pg_execute <OPTIONAL>-array <REPLACEABLE CLASS="PARAMETER">arrayVar</REPLACEABLE
|
||||
<LISTITEM>
|
||||
<PARA>Specifies the name of an array variable where result tuples are stored,
|
||||
indexed by the field names.
|
||||
This is ignored if queryString is not a SELECT statement. For SELECT
|
||||
This is ignored if <replaceable class=parameter>queryString</> is not a SELECT statement. For SELECT
|
||||
statements, if this option is not used, result tuples values are stored
|
||||
in individual variables named according to the field names in the result.
|
||||
</PARA>
|
||||
@ -1118,7 +1118,7 @@ The number of tuples affected or returned by the query.
|
||||
If the query is not a SELECT statement, the query is executed and the
|
||||
number of tuples affected by the query is returned. If the query is an
|
||||
INSERT and a single tuple is inserted, the OID of the inserted tuple is
|
||||
stored in the oidVar variable if the optional <PARAMETER>-oid</PARAMETER>
|
||||
stored in the <replaceable>oidVar</> variable if the optional <PARAMETER>-oid</PARAMETER>
|
||||
argument is supplied.
|
||||
</PARA>
|
||||
<PARA>
|
||||
@ -1166,7 +1166,7 @@ In the following examples, error checking with <LITERAL>catch</LITERAL>
|
||||
has been omitted for clarity.
|
||||
</PARA>
|
||||
<PARA>
|
||||
Insert a row and save the OID in result_oid:
|
||||
Insert a row and save the OID in <varname>result_oid</>:
|
||||
<ProgramListing>
|
||||
pg_execute -oid result_oid $pgconn "insert into mytable values (1)"
|
||||
</ProgramListing>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.96 2002/09/05 22:09:42 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.97 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
@ -214,7 +214,7 @@ PGconn *PQconnectdb(const char *conninfo)
|
||||
environment variable (see <xref linkend="libpq-envars">)
|
||||
is checked. If the environment variable is not set either,
|
||||
then hardwired defaults are used.
|
||||
The return value is a pointer to an abstract struct
|
||||
The return value is a pointer to an abstract <type>struct</type>
|
||||
representing the connection to the backend.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -457,7 +457,7 @@ struct PQconninfoOption
|
||||
Returns a connection options array. This may
|
||||
be used to determine all possible <function>PQconnectdb</function> options and their
|
||||
current default values. The return value points to an array of
|
||||
<structname>PQconninfoOption</structname> structs, which ends with an entry having a NULL
|
||||
<structname>PQconninfoOption</structname> <type>struct</>s, which ends with an entry having a NULL
|
||||
keyword pointer. Note that the default values (<structfield>val</structfield> fields)
|
||||
will depend on environment variables and other context.
|
||||
Callers must treat the connection options data as read-only.
|
||||
@ -542,7 +542,7 @@ maintain the <structname>PGconn</structname> abstraction. Use the accessor func
|
||||
at the contents of <structname>PGconn</structname>. Avoid directly referencing the fields of the
|
||||
<structname>PGconn</> structure because they are subject to change in the future.
|
||||
(Beginning in <productname>PostgreSQL</productname> release 6.4, the
|
||||
definition of struct <structname>PGconn</structname> is not even provided in <filename>libpq-fe.h</filename>.
|
||||
definition of <type>struct PGconn</> is not even provided in <filename>libpq-fe.h</filename>.
|
||||
If you have old code that accesses <structname>PGconn</structname> fields directly, you can keep using it
|
||||
by including <filename>libpq-int.h</filename> too, but you are encouraged to fix the code
|
||||
soon.)
|
||||
@ -757,7 +757,7 @@ maintain the <structname>PGresult</structname> abstraction. Use the accessor fu
|
||||
at the contents of <structname>PGresult</structname>. Avoid directly referencing the fields of the
|
||||
<structname>PGresult</structname> structure because they are subject to change in the future.
|
||||
(Beginning in <productname>PostgreSQL</productname> 6.4, the
|
||||
definition of struct <structname>PGresult</structname> is not even provided in <filename>libpq-fe.h</>. If you
|
||||
definition of <type>struct PGresult</> is not even provided in <filename>libpq-fe.h</>. If you
|
||||
have old code that accesses <structname>PGresult</structname> fields directly, you can keep using it
|
||||
by including <filename>libpq-int.h</filename> too, but you are encouraged to fix the code
|
||||
soon.)
|
||||
@ -813,7 +813,7 @@ exposes a bug in the client software.
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQresStatus</function>
|
||||
Converts the enumerated type returned by PQresultStatus into
|
||||
Converts the enumerated type returned by <function>PQresultStatus</> into
|
||||
a string constant describing the status code.
|
||||
<synopsis>
|
||||
char *PQresStatus(ExecStatusType status);
|
||||
@ -868,7 +868,7 @@ This is <application>libpq</>'s internal routine to allocate and initialize an e
|
||||
<structname>PGresult</structname> object. It is exported because some applications find it
|
||||
useful to generate result objects (particularly objects with error
|
||||
status) themselves. If <parameter>conn</parameter> is not NULL and status indicates an error,
|
||||
the connection's current errorMessage is copied into the <structname>PGresult.</structname>
|
||||
the connection's current error message is copied into the <structname>PGresult.</structname>
|
||||
Note that <function>PQclear</function> should eventually be called on the object, just
|
||||
as with a <structname>PGresult</structname> returned by <application>libpq</application> itself.
|
||||
</para>
|
||||
@ -976,7 +976,7 @@ strings overlap.
|
||||
The <parameter>from</parameter> parameter points to an escaped string
|
||||
such as might be returned by <function>PQgetvalue</function> of a
|
||||
<type>BYTEA</type> column. <function>PQunescapeBytea</function> converts
|
||||
this NUL terminated string representation into binary, filling a buffer.
|
||||
this string representation into its binary representation, filling the supplied buffer.
|
||||
It returns a pointer to the buffer which is NULL on error, and the size
|
||||
of the buffer in <parameter>to_length</parameter>. The pointer may
|
||||
subsequently be used as an argument to the function
|
||||
@ -1092,7 +1092,7 @@ int PQfsize(const PGresult *res,
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQbinaryTuples</function>
|
||||
Returns 1 if the PGresult contains binary tuple data,
|
||||
Returns 1 if the <structname>PGresult</> contains binary tuple data,
|
||||
0 if it contains ASCII data.
|
||||
<synopsis>
|
||||
int PQbinaryTuples(const PGresult *res);
|
||||
@ -1392,7 +1392,7 @@ PGresult *PQgetResult(PGconn *conn);
|
||||
indicating that the command is done. (If called when no command is
|
||||
active, <function>PQgetResult</function> will just return NULL at once.)
|
||||
Each non-NULL result from <function>PQgetResult</function> should be processed using
|
||||
the same PGresult accessor functions previously described.
|
||||
the same <structname>PGresult</> accessor functions previously described.
|
||||
Don't forget to free each result object with <function>PQclear</function> when done with it.
|
||||
Note that <function>PQgetResult</function> will block only if a query is active and the
|
||||
necessary response data has not yet been read by <function>PQconsumeInput</function>.
|
||||
@ -1606,7 +1606,7 @@ typedef struct {
|
||||
} u;
|
||||
} PQArgBlock;
|
||||
</synopsis>
|
||||
<function>PQfn</function> always returns a valid <structname>PGresult*</structname>. The resultStatus
|
||||
<function>PQfn</function> always returns a valid <structname>PGresult*</structname>. The result status
|
||||
should be checked before the result is used. The
|
||||
caller is responsible for freeing the <structname>PGresult</structname> with
|
||||
<function>PQclear</function> when it is no longer needed.
|
||||
@ -1647,7 +1647,7 @@ messages can be detected by calling <function>PQnotifies</function>.
|
||||
Returns the next notification from a list of unhandled
|
||||
notification messages received from the backend. Returns NULL if
|
||||
there are no pending notifications. Once a notification is
|
||||
returned from PQnotifies, it is considered handled and will be
|
||||
returned from <function>PQnotifies</>, it is considered handled and will be
|
||||
removed from the list of notifications.
|
||||
<synopsis>
|
||||
PGnotify* PQnotifies(PGconn *conn);
|
||||
@ -1932,7 +1932,7 @@ void PQuntrace(PGconn *conn)
|
||||
<para>
|
||||
<function>PQsetNoticeProcessor</function>
|
||||
<indexterm><primary>notice processor</></>
|
||||
Control reporting of notice and warning messages generated by libpq.
|
||||
Control reporting of notice and warning messages generated by <application>libpq</>.
|
||||
<synopsis>
|
||||
typedef void (*PQnoticeProcessor) (void *arg, const char *message);
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.18 2002/09/18 20:09:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.19 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -380,14 +380,14 @@ VACUUM
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> is unable to reuse btree index
|
||||
<productname>PostgreSQL</productname> is unable to reuse B-tree index
|
||||
pages in certain cases. The problem is that if indexed rows are
|
||||
deleted, those index pages can only be reused by rows with similar
|
||||
values. For example, if indexed rows are deleted and newly
|
||||
inserted/updated rows have much higher values, the new rows can't use
|
||||
the index space made available by the deleted rows. Instead, such
|
||||
new rows must be placed on new index pages. In such cases, disk
|
||||
space used by the index will grow indefinately, even if
|
||||
space used by the index will grow indefinitely, even if
|
||||
<command>VACUUM</> is run frequently.
|
||||
</para>
|
||||
<para>
|
||||
@ -426,7 +426,7 @@ VACUUM
|
||||
The simplest production-grade approach to managing log output is to
|
||||
send it all to <application>syslog</> and let
|
||||
<application>syslog</> deal with file rotation. To do this, set
|
||||
<literal>syslog</> to 2 (log to syslog only) in
|
||||
<literal>syslog</> to 2 (log to <application>syslog</> only) in
|
||||
<filename>postgresql.conf</>. Then you can send a
|
||||
<literal>SIGHUP</literal> signal to the <application>syslog</>
|
||||
daemon whenever you want to force it to start writing a new log
|
||||
@ -434,7 +434,7 @@ VACUUM
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On many systems, however, syslog is not very reliable, particularly
|
||||
On many systems, however, <application>syslog</> is not very reliable, particularly
|
||||
with large log messages; it may truncate or drop messages just when
|
||||
you need them the most. You may find it more useful to pipe the
|
||||
<application>postmaster</>'s <systemitem>stderr</> to some type of
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.13 2002/08/31 17:14:27 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.14 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="monitoring">
|
||||
@ -172,7 +172,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
Each individual server process transmits new access counts to the collector
|
||||
just before waiting for another client command; so a query still in
|
||||
progress does not affect the displayed totals. Also, the collector itself
|
||||
emits new totals at most once per PGSTAT_STAT_INTERVAL (500 milliseconds
|
||||
emits new totals at most once per <varname>pgstat_stat_interval</varname> (500 milliseconds
|
||||
by default). So the displayed totals lag behind actual activity.
|
||||
</para>
|
||||
|
||||
@ -204,7 +204,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><structname>pg_stat_activity</></entry>
|
||||
<entry>One row per server process, showing process PID, database,
|
||||
<entry>One row per server process, showing process <acronym>PID</>, database,
|
||||
user, and current query. The current query column is only available
|
||||
to superusers; for others it reads as NULL. (Note that because of
|
||||
the collector's reporting delay, current query will only be up-to-date
|
||||
@ -274,13 +274,13 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_sys_tables</></entry>
|
||||
<entry>Same as pg_statio_all_tables, except that only system tables
|
||||
<entry>Same as <structname>pg_statio_all_tables</>, except that only system tables
|
||||
are shown.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_user_tables</></entry>
|
||||
<entry>Same as pg_statio_all_tables, except that only user tables
|
||||
<entry>Same as <structname>pg_statio_all_tables</>, except that only user tables
|
||||
are shown.</entry>
|
||||
</row>
|
||||
|
||||
@ -293,13 +293,13 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_sys_indexes</></entry>
|
||||
<entry>Same as pg_statio_all_indexes, except that only indexes on
|
||||
<entry>Same as <structname>pg_statio_all_indexes</>, except that only indexes on
|
||||
system tables are shown.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_user_indexes</></entry>
|
||||
<entry>Same as pg_statio_all_indexes, except that only indexes on
|
||||
<entry>Same as <structname>pg_statio_all_indexes</>, except that only indexes on
|
||||
user tables are shown.</entry>
|
||||
</row>
|
||||
|
||||
@ -312,14 +312,14 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_sys_sequences</></entry>
|
||||
<entry>Same as pg_statio_all_sequences, except that only system
|
||||
<entry>Same as <structname>pg_statio_all_sequences</>, except that only system
|
||||
sequences are shown. (Presently, no system sequences are defined,
|
||||
so this view is always empty.)</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structname>pg_statio_user_sequences</></entry>
|
||||
<entry>Same as pg_statio_all_sequences, except that only user
|
||||
<entry>Same as <structname>pg_statio_all_sequences</>, except that only user
|
||||
sequences are shown.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -540,7 +540,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<para>
|
||||
The function <function>pg_stat_get_backend_idset</function> provides
|
||||
a convenient way to generate one row for each active backend. For
|
||||
example, to show the PIDs and current queries of all backends:
|
||||
example, to show the <acronym>PID</>s and current queries of all backends:
|
||||
|
||||
<programlisting>
|
||||
SELECT pg_stat_get_backend_pid(S.backendid) AS procpid,
|
||||
@ -657,10 +657,10 @@ FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S;
|
||||
<entry><structfield>transaction</structfield></entry>
|
||||
<entry><type>xid</type></entry>
|
||||
<entry>The ID of a transaction, or NULL if the lockable object
|
||||
is a relation. Every transaction holds ExclusiveLock on its
|
||||
is a relation. Every transaction holds an exclusive lock on its
|
||||
transaction ID for its entire duration. If one transaction finds
|
||||
it necessary to wait specifically for another transaction, it
|
||||
does so by attempting to acquire ShareLock on the other transaction
|
||||
does so by attempting to acquire share lock on the other transaction
|
||||
ID. That will succeed only when the other transaction terminates
|
||||
and releases its locks.
|
||||
</entry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.27 2002/08/17 13:04:14 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.28 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="mvcc">
|
||||
@ -498,7 +498,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
EXCLUSIVE</literal>, <literal>EXCLUSIVE</literal>, and
|
||||
<literal>ACCESS EXCLUSIVE</literal> lock modes.
|
||||
This mode protects a table against
|
||||
concurrent schema changes and VACUUMs.
|
||||
concurrent schema changes and <command>VACUUM</> runs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.20 2002/03/24 17:11:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.21 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="performance-tips">
|
||||
@ -527,11 +527,11 @@ regression=#
|
||||
</sect1>
|
||||
|
||||
<sect1 id="explicit-joins">
|
||||
<title>Controlling the Planner with Explicit JOINs</title>
|
||||
<title>Controlling the Planner with Explicit <literal>JOIN</> Clauses</title>
|
||||
|
||||
<para>
|
||||
Beginning with <productname>PostgreSQL</productname> 7.1 it is possible
|
||||
to control the query planner to some extent by using explicit JOIN
|
||||
to control the query planner to some extent by using explicit <literal>JOIN</>
|
||||
syntax. To see why this matters, we first need some background.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.17 2002/09/18 20:09:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.18 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plperl">
|
||||
@ -162,7 +162,7 @@ SELECT name, empcomp(employee) FROM employee;
|
||||
Access to the database itself from your Perl function can be done via
|
||||
an experimental module <ulink
|
||||
url="http://www.cpan.org/modules/by-module/DBD/APILOS/"><literal>DBD::PgSPI</literal></ulink>
|
||||
(also available at <ulink url="http://www.cpan.org/SITES.html">CPAN
|
||||
(also available at <ulink url="http://www.cpan.org/SITES.html"><acronym>CPAN</>
|
||||
mirror sites</ulink>). This module makes available a
|
||||
<acronym>DBI</>-compliant database-handle named
|
||||
<varname>$pg_dbh</varname> that can be used to perform queries
|
||||
@ -230,14 +230,14 @@ CREATE FUNCTION badfunc() RETURNS integer AS '
|
||||
restricted --- for example, one might want a Perl function that
|
||||
sends mail. To handle these cases, PL/Perl can also be installed
|
||||
as an <quote>untrusted</> language (usually called
|
||||
<quote>PL/PerlU</quote>). In this case the full Perl language is
|
||||
<application>PL/PerlU</application>). In this case the full Perl language is
|
||||
available. If the <command>createlang</command> program is used to
|
||||
install the language, the language name <literal>plperlu</literal>
|
||||
will select the untrusted PL/Perl variant.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The writer of a PL/PerlU function must take care that the function
|
||||
The writer of a <application>PL/PerlU</> function must take care that the function
|
||||
cannot be used to do anything unwanted, since it will be able to do
|
||||
anything that could be done by a user logged in as the database
|
||||
administrator. Note that the database system allows only database
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.7 2002/09/14 20:11:16 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.8 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -126,7 +126,7 @@ END;
|
||||
The <application>PL/pgSQL</application> EXECUTE statement is not
|
||||
related to the EXECUTE statement supported by the
|
||||
<productname>PostgreSQL</productname> backend. The backend
|
||||
EXECUTE statement cannot be used within PL/PgSQL functions (and
|
||||
EXECUTE statement cannot be used within <application>PL/pgSQL</> functions (and
|
||||
is not needed).
|
||||
</para>
|
||||
</note>
|
||||
@ -849,7 +849,7 @@ SELECT INTO <replaceable>target</replaceable> <replaceable>expressions</replacea
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the SELECT query returns zero rows, NULLs are assigned to the
|
||||
If the SELECT query returns zero rows, null values are assigned to the
|
||||
target(s). If the SELECT query returns multiple rows, the first
|
||||
row is assigned to the target(s) and the rest are discarded.
|
||||
(Note that <quote>the first row</> is not well-defined unless you've
|
||||
@ -877,8 +877,8 @@ IF NOT FOUND THEN
|
||||
END IF;
|
||||
</programlisting>
|
||||
|
||||
Alternatively, you can use the IS NULL (or ISNULL) conditional to
|
||||
test for NULLity of a RECORD/ROW result. Note that there is no
|
||||
Alternatively, you can use the <literal>IS NULL</literal> (or <literal>ISNULL</>) conditional to
|
||||
test for whether a RECORD/ROW result is null. Note that there is no
|
||||
way to tell whether any additional rows might have been discarded.
|
||||
</para>
|
||||
|
||||
@ -1205,7 +1205,7 @@ RETURN NEXT <replaceable>expression</replaceable>;
|
||||
|
||||
RETURN NEXT does not actually return from the function; it simply
|
||||
saves away the value of the expression (or record or row variable,
|
||||
as appropriate for the datatype being returned).
|
||||
as appropriate for the data type being returned).
|
||||
Execution then continues with the next statement in the
|
||||
<application>PL/pgSQL</> function. As successive RETURN NEXT
|
||||
commands are executed, the result set is built up. A final
|
||||
@ -1215,17 +1215,17 @@ RETURN NEXT <replaceable>expression</replaceable>;
|
||||
|
||||
<note>
|
||||
<para>
|
||||
The current implementation of RETURN NEXT for PL/PgSQL stores
|
||||
the entire result set before returning from the function, as
|
||||
discussed above. That means that if a PL/PgSQL function
|
||||
produces a very large result set, performance may be poor: data
|
||||
will be written to disk to avoid memory exhaustion, but the
|
||||
function itself will not return until the entire
|
||||
result set has been generated. A future version of PL/PgSQL may
|
||||
allow users to allow users to define set-returning functions
|
||||
that do not have this limitation. Currently, the point at which
|
||||
data begins being written to disk is controlled by the
|
||||
<option>SORT_MEM</> configuration variable. Administrators who
|
||||
The current implementation of RETURN NEXT for
|
||||
<application>PL/pgSQL</> stores the entire result set before
|
||||
returning from the function, as discussed above. That means that
|
||||
if a <application>PL/pgSQL</> function produces a very large result set,
|
||||
performance may be poor: data will be written to disk to avoid
|
||||
memory exhaustion, but the function itself will not return until
|
||||
the entire result set has been generated. A future version of
|
||||
<application>PL/pgSQL</> may allow users to allow users to define set-returning
|
||||
functions that do not have this limitation. Currently, the point
|
||||
at which data begins being written to disk is controlled by the
|
||||
<varname>SORT_MEM</> configuration variable. Administrators who
|
||||
have sufficient memory to store larger result sets in memory
|
||||
should consider increasing this parameter.
|
||||
</para>
|
||||
@ -1236,14 +1236,27 @@ RETURN NEXT <replaceable>expression</replaceable>;
|
||||
<title>Conditionals</title>
|
||||
|
||||
<para>
|
||||
<function>IF</function> statements let you execute commands based on
|
||||
certain conditions.
|
||||
<application>PL/pgSQL</> has four forms of IF: IF-THEN, IF-THEN-ELSE,
|
||||
IF-THEN-ELSE IF, and IF-THEN-ELSIF-THEN-ELSE.
|
||||
<literal>IF</> statements let you execute commands based on
|
||||
certain conditions. <application>PL/pgSQL</> has four forms of
|
||||
<literal>IF</>:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><literal>IF ... THEN</></>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>IF ... THEN ... ELSE</></>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>IF ... THEN ... ELSE IF</> and</>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>IF ... THEN ... ELSIF ... THEN ... ELSE</></>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>IF-THEN</title>
|
||||
<title><literal>IF-THEN</></title>
|
||||
|
||||
<para>
|
||||
<synopsis>
|
||||
@ -1265,7 +1278,7 @@ END IF;
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>IF-THEN-ELSE</title>
|
||||
<title><literal>IF-THEN-ELSE</></title>
|
||||
|
||||
<para>
|
||||
<synopsis>
|
||||
@ -1300,7 +1313,7 @@ END IF;
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>IF-THEN-ELSE IF</title>
|
||||
<title><literal>IF-THEN-ELSE IF</></title>
|
||||
|
||||
<para>
|
||||
IF statements can be nested, as in the following example:
|
||||
@ -1326,7 +1339,7 @@ END IF;
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>IF-THEN-ELSIF-ELSE</title>
|
||||
<title><literal>IF-THEN-ELSIF-ELSE</></title>
|
||||
|
||||
<para>
|
||||
<synopsis>
|
||||
@ -1344,10 +1357,11 @@ IF <replaceable>boolean-expression</replaceable> THEN
|
||||
END IF;
|
||||
</synopsis>
|
||||
|
||||
IF-THEN-ELSIF-ELSE provides a more convenient method of checking
|
||||
many alternatives in one statement. Formally it is equivalent
|
||||
to nested IF-THEN-ELSE-IF-THEN commands, but only one END IF
|
||||
is needed.
|
||||
<literal>IF-THEN-ELSIF-ELSE</> provides a more convenient
|
||||
method of checking many alternatives in one statement.
|
||||
Formally it is equivalent to nested
|
||||
<literal>IF-THEN-ELSE-IF-THEN</> commands, but only one
|
||||
<literal>END IF</> is needed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1673,7 +1687,7 @@ OPEN <replaceable>unbound-cursor</replaceable> FOR SELECT ...;
|
||||
to execute. The cursor cannot be open already, and it must
|
||||
have been declared as an unbound cursor (that is, as a simple
|
||||
<type>refcursor</> variable). The SELECT query is treated
|
||||
in the same way as other SELECTs in <application>PL/pgSQL</>:
|
||||
in the same way as other SELECT statements in <application>PL/pgSQL</>:
|
||||
<application>PL/pgSQL</> variable names are substituted,
|
||||
and the query plan is cached for possible re-use.
|
||||
|
||||
@ -1706,7 +1720,7 @@ OPEN curs1 FOR EXECUTE ''SELECT * FROM '' || quote_ident($1);
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>OPENing a bound cursor</title>
|
||||
<title>Opening a bound cursor</title>
|
||||
|
||||
<para>
|
||||
<synopsis>
|
||||
@ -1802,7 +1816,7 @@ CLOSE curs1;
|
||||
caller. This is used to return multiple rows or columns from the
|
||||
function. The function opens the cursor and returns the cursor
|
||||
name to the caller. The caller can then FETCH rows from the
|
||||
cursor. The cursor can be CLOSEd by the caller, or it will be
|
||||
cursor. The cursor can be closed by the caller, or it will be
|
||||
closed automatically when the transaction closes.
|
||||
|
||||
</para>
|
||||
@ -2067,7 +2081,7 @@ RAISE EXCEPTION ''Inexistent ID --> %'',user_id;
|
||||
Data type array of <type>text</type>; the arguments from
|
||||
the <command>CREATE TRIGGER</command> statement.
|
||||
The index counts from 0 and can be given as an expression. Invalid
|
||||
indices (< 0 or >= tg_nargs) result in a NULL value.
|
||||
indices (< 0 or >= <varname>tg_nargs</>) result in a null value.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2387,7 +2401,7 @@ LANGUAGE 'plpgsql';
|
||||
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>In assignments, SELECTs, to delimit strings, etc.</entry>
|
||||
<entry>In assignments, SELECT statements, to delimit strings, etc.</entry>
|
||||
<entry><programlisting>
|
||||
a_output := ''Blah'';
|
||||
SELECT * FROM users WHERE f_name=''foobar'';
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.11 2002/09/18 20:09:32 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.12 2002/09/21 18:32:53 petere Exp $ -->
|
||||
|
||||
<chapter id="plpython">
|
||||
<title>PL/Python - Python Procedural Language</title>
|
||||
@ -221,9 +221,12 @@ plan = plpy.prepare("SOME OTHER QUERY")
|
||||
execution environment, further restricts it to prevent the use of
|
||||
the file <function>open</> call, and allows only modules from a
|
||||
specific list to be imported. Presently, that list includes:
|
||||
array, bisect, binascii, calendar, cmath, codecs, errno, marshal,
|
||||
math, md5, mpz, operator, pcre, pickle, random, re, regex, sre,
|
||||
sha, string, StringIO, struct, time, whrandom, and zlib.
|
||||
<literal>array</>, <>bisect</>, <>binascii</>, <>calendar</>,
|
||||
<>cmath</>, <>codecs</>, <>errno</>, <>marshal</>, <>math</>,
|
||||
<>md5</>, <>mpz</>, <>operator</>, <>pcre</>, <>pickle</>,
|
||||
<>random</>, <>re</>, <>regex</>, <>sre</>, <>sha</>, <>string</>,
|
||||
<>StringIO</>, <>struct</>, <>time</>, <>whrandom</>, and
|
||||
<>zlib</>.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.21 2002/08/22 00:01:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.22 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="pltcl">
|
||||
@ -50,22 +50,22 @@ $Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.21 2002/08/22 00:01:40 tgl E
|
||||
<para>
|
||||
Sometimes it is desirable to write Tcl functions that are not restricted
|
||||
to safe Tcl --- for example, one might want a Tcl function that sends
|
||||
mail. To handle these cases, there is a variant of PL/Tcl called PL/TclU
|
||||
mail. To handle these cases, there is a variant of <application>PL/Tcl</> called <literal>PL/TclU</>
|
||||
(for untrusted Tcl). This is the exact same language except that a full
|
||||
Tcl interpreter is used. <emphasis>If PL/TclU is used, it must be
|
||||
Tcl interpreter is used. <emphasis>If <application>PL/TclU</> is used, it must be
|
||||
installed as an untrusted procedural language</emphasis> so that only
|
||||
database superusers can create functions in it. The writer of a PL/TclU
|
||||
database superusers can create functions in it. The writer of a <application>PL/TclU</>
|
||||
function must take care that the function cannot be used to do anything
|
||||
unwanted, since it will be able to do anything that could be done by
|
||||
a user logged in as the database administrator.
|
||||
</para>
|
||||
<para>
|
||||
The shared object for the PL/Tcl and PL/TclU call handlers is
|
||||
The shared object for the <application>PL/Tcl</> and <application>PL/TclU</> call handlers is
|
||||
automatically built and installed in the
|
||||
<productname>PostgreSQL</productname>
|
||||
library directory if Tcl/Tk support is specified
|
||||
in the configuration step of the installation procedure. To install
|
||||
PL/Tcl and/or PL/TclU in a particular database, use the
|
||||
<application>PL/Tcl</> and/or <application>PL/TclU</> in a particular database, use the
|
||||
<filename>createlang</filename> script, for example
|
||||
<literal>createlang pltcl <replaceable>dbname</></literal> or
|
||||
<literal>createlang pltclu <replaceable>dbname</></literal>.
|
||||
@ -81,7 +81,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.21 2002/08/22 00:01:40 tgl E
|
||||
<title>PL/Tcl Functions and Arguments</title>
|
||||
|
||||
<para>
|
||||
To create a function in the PL/Tcl language, use the standard syntax
|
||||
To create a function in the <application>PL/Tcl</> language, use the standard syntax
|
||||
|
||||
<programlisting>
|
||||
CREATE FUNCTION <replaceable>funcname</replaceable> (<replaceable>argument-types</replaceable>) RETURNS <replaceable>return-type</replaceable> AS '
|
||||
@ -89,8 +89,8 @@ CREATE FUNCTION <replaceable>funcname</replaceable> (<replaceable>argument-types
|
||||
' LANGUAGE 'pltcl';
|
||||
</programlisting>
|
||||
|
||||
PL/TclU is the same, except that the language should be specified as
|
||||
<literal>'pltclu'</>.
|
||||
<application>PL/TclU</> is the same, except that the language should be specified as
|
||||
<literal>pltclu</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -197,7 +197,7 @@ CREATE FUNCTION overpaid_2 (EMP) RETURNS bool AS '
|
||||
all PL/Tcl procedures executed in one backend share the same
|
||||
safe Tcl interpreter. So, any global Tcl variable is accessible to
|
||||
all PL/Tcl procedure calls, and will persist for the duration of the
|
||||
SQL client connection. (Note that PL/TclU functions likewise share
|
||||
SQL client connection. (Note that <application>PL/TclU</> functions likewise share
|
||||
global data, but they are in a different Tcl interpreter and cannot
|
||||
communicate with PL/Tcl functions.)
|
||||
</para>
|
||||
@ -248,7 +248,7 @@ CREATE FUNCTION overpaid_2 (EMP) RETURNS bool AS '
|
||||
setting up the query as a cursor and then saying <literal>FETCH n</>.
|
||||
</para>
|
||||
<para>
|
||||
If the query is a SELECT statement, the values of the SELECT's
|
||||
If the query is a <literal>SELECT</> statement, the values of the statement's
|
||||
result columns are placed into Tcl variables named after the columns.
|
||||
If the <literal>-array</> option is given, the column values are
|
||||
instead stored into the named associative array, with the SELECT
|
||||
@ -267,7 +267,7 @@ spi_exec "SELECT count(*) AS cnt FROM pg_proc"
|
||||
</programlisting>
|
||||
|
||||
will set the Tcl variable <literal>$cnt</> to the number of rows in
|
||||
the pg_proc system catalog.
|
||||
the <structname>pg_proc</> system catalog.
|
||||
</para>
|
||||
<para>
|
||||
If the optional <replaceable>loop-body</> argument is given, it is
|
||||
@ -337,7 +337,7 @@ spi_exec -array C "SELECT * FROM pg_class" {
|
||||
<para>
|
||||
The optional value for <literal>-nulls</> is a string of spaces and
|
||||
<literal>'n'</> characters telling <function>spi_execp</function>
|
||||
which of the arguments are NULLs. If given, it must have exactly the
|
||||
which of the arguments are null values. If given, it must have exactly the
|
||||
same length as the <replaceable>value-list</replaceable>. If it
|
||||
is not given, all the argument values are non-NULL.
|
||||
</para>
|
||||
@ -504,7 +504,7 @@ SELECT 'doesn''t' AS ret
|
||||
<listitem>
|
||||
<para>
|
||||
A Tcl list of the table field names, prefixed with an empty list
|
||||
element. So looking up an element name in the list with Tcl's
|
||||
element. So looking up an element name in the list with <application>Tcl</>'s
|
||||
<function>lsearch</> command returns the element's number starting
|
||||
with 1 for the first column, the same way the fields are customarily
|
||||
numbered in <productname>PostgreSQL</productname>.
|
||||
@ -639,7 +639,7 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
|
||||
While the <literal>unknown</> module could actually contain any
|
||||
initialization script you need, it normally defines a Tcl
|
||||
<quote>unknown</> procedure that is invoked whenever Tcl does
|
||||
not recognize an invoked procedure name. PL/Tcl's standard version
|
||||
not recognize an invoked procedure name. <application>PL/Tcl</>'s standard version
|
||||
of this procedure tries to find a module in <literal>pltcl_modules</>
|
||||
that will define the required procedure. If one is found, it is
|
||||
loaded into the interpreter, and then execution is allowed to
|
||||
@ -674,7 +674,7 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
|
||||
differ. Tcl, however, requires all procedure names to be distinct.
|
||||
PL/Tcl deals with this by making the internal Tcl procedure names contain
|
||||
the object
|
||||
ID of the procedure's pg_proc row as part of their name. Thus,
|
||||
ID of the procedure's <structname>pg_proc</> row as part of their name. Thus,
|
||||
<productname>PostgreSQL</productname> functions with the same name
|
||||
and different argument types will be different Tcl procedures too. This
|
||||
is not normally a concern for a PL/Tcl programmer, but it might be visible
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.41 2002/09/18 20:07:15 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/programmer.sgml,v 1.42 2002/09/21 18:32:53 petere Exp $
|
||||
|
||||
PostgreSQL Programmer's Guide.
|
||||
-->
|
||||
@ -60,7 +60,6 @@ PostgreSQL Programmer's Guide.
|
||||
&rules;
|
||||
&xindex;
|
||||
&indexcost;
|
||||
&gist;
|
||||
&trigger;
|
||||
&spi;
|
||||
</part>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.49 2002/08/15 02:59:18 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.50 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -249,7 +249,7 @@ ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
|
||||
<para>
|
||||
These forms change whether a column is marked to allow NULL
|
||||
values or to reject NULL values. You may only <literal>SET NOT NULL</>
|
||||
when the table contains no NULLs in the column.
|
||||
when the table contains no null values in the column.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -279,7 +279,7 @@ ALTER TABLE <replaceable class="PARAMETER">table</replaceable>
|
||||
compressible data. <literal>EXTERNAL</literal> is for external,
|
||||
uncompressed data and <literal>EXTENDED</literal> is for external,
|
||||
compressed data. <literal>EXTENDED</literal> is the default for all
|
||||
datatypes that support it. The use of <literal>EXTERNAL</literal> will
|
||||
data types that support it. The use of <literal>EXTERNAL</literal> will
|
||||
make substring operations on a TEXT column faster, at the penalty of
|
||||
increased storage space.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_user.sgml,v 1.22 2002/05/17 01:19:16 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/alter_user.sgml,v 1.23 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -226,7 +226,7 @@ ALTER USER manuel VALID UNTIL 'Jan 31 2030';
|
||||
<para>
|
||||
Change a user's valid until date, specifying that his
|
||||
authorization should expire at midday on 4th May 1998 using
|
||||
the time zone which is one hour ahead of UTC:
|
||||
the time zone which is one hour ahead of <acronym>UTC</>:
|
||||
<programlisting>
|
||||
ALTER USER chris VALID UNTIL 'May 4 12:00:00 1998 +1';
|
||||
</programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/begin.sgml,v 1.19 2002/08/30 22:45:25 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/begin.sgml,v 1.20 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -125,7 +125,7 @@ WARNING: BEGIN: already a transaction in progress
|
||||
Guide</citetitle> for details.)
|
||||
In SERIALIZABLE mode queries will see only changes committed before
|
||||
the entire
|
||||
transaction began (actually, before execution of the first DML statement
|
||||
transaction began (actually, before execution of the first <acronym>DML</> statement
|
||||
in the transaction).
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/cluster.sgml,v 1.19 2002/08/11 02:43:57 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/cluster.sgml,v 1.20 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -169,7 +169,7 @@ SELECT <replaceable class="parameter">columnlist</replaceable> INTO TABLE <repla
|
||||
|
||||
which uses the <productname>PostgreSQL</productname> sorting code in
|
||||
the ORDER BY clause to create the desired order; this is usually much
|
||||
faster than an indexscan for
|
||||
faster than an index scan for
|
||||
unordered data. You then drop the old table, use
|
||||
<command>ALTER TABLE...RENAME</command>
|
||||
to rename <replaceable class="parameter">newtable</replaceable> to the old name, and
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/clusterdb.sgml,v 1.3 2002/09/05 22:05:50 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/clusterdb.sgml,v 1.4 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -71,8 +71,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-d <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term>--dbname <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term><option>-d <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<term><option>--dbname <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the name of the database to be clustered.
|
||||
@ -86,8 +86,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-a</term>
|
||||
<term>--all</term>
|
||||
<term><option>-a</></term>
|
||||
<term><option>--all</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Cluster all databases.
|
||||
@ -96,8 +96,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-t <replaceable class="parameter">table</replaceable></term>
|
||||
<term>--table <replaceable class="parameter">table</replaceable></term>
|
||||
<term><option>-t <replaceable class="parameter">table</replaceable></></term>
|
||||
<term><option>--table <replaceable class="parameter">table</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Clusters <replaceable class="parameter">table</replaceable> only.
|
||||
@ -114,8 +114,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h <replaceable class="parameter">host</replaceable></term>
|
||||
<term>--host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -127,8 +127,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p <replaceable class="parameter">port</replaceable></term>
|
||||
<term>--port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -139,8 +139,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U <replaceable class="parameter">username</replaceable></term>
|
||||
<term>--username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -149,8 +149,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W</term>
|
||||
<term>--password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
@ -159,8 +159,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e</term>
|
||||
<term>--echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the commands that <application>clusterdb</application> generates
|
||||
@ -170,8 +170,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q</term>
|
||||
<term>--quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.39 2002/08/30 16:00:41 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.40 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -477,7 +477,7 @@ order is detected here.
|
||||
<listitem>
|
||||
<para>
|
||||
int32 bit mask to denote important aspects of the file format. Bits are
|
||||
numbered from 0 (LSB) to 31 (MSB) --- note that this field is stored
|
||||
numbered from 0 (<acronym>LSB</>) to 31 (<acronym>MSB</>) --- note that this field is stored
|
||||
with source's endianness, as are all subsequent integer fields. Bits
|
||||
16-31 are reserved to denote critical file format issues; a reader
|
||||
should abort if it finds an unexpected bit set in this range. Bits 0-15
|
||||
@ -539,8 +539,8 @@ is left for a later release.
|
||||
Each tuple begins with an int16 count of the number of fields in the
|
||||
tuple. (Presently, all tuples in a table will have the same count, but
|
||||
that might not always be true.) Then, repeated for each field in the
|
||||
tuple, there is an int16 typlen word possibly followed by field data.
|
||||
The typlen field is interpreted thus:
|
||||
tuple, there is an int16 <structfield>typlen</> word possibly followed by field data.
|
||||
The <structfield>typlen</> field is interpreted thus:
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -557,7 +557,7 @@ The typlen field is interpreted thus:
|
||||
<listitem>
|
||||
<para>
|
||||
Field is a fixed-length data type. Exactly N
|
||||
bytes of data follow the typlen word.
|
||||
bytes of data follow the <structfield>typlen</> word.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -566,8 +566,8 @@ The typlen field is interpreted thus:
|
||||
<term>-1</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Field is a varlena data type. The next four
|
||||
bytes are the varlena header, which contains
|
||||
Field is a <literal>varlena</> data type. The next four
|
||||
bytes are the <literal>varlena</> header, which contains
|
||||
the total value length including itself.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -585,8 +585,8 @@ The typlen field is interpreted thus:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For non-NULL fields, the reader can check that the typlen matches the
|
||||
expected typlen for the destination column. This provides a simple
|
||||
For non-NULL fields, the reader can check that the <structfield>typlen</> matches the
|
||||
expected <structfield>typlen</> for the destination column. This provides a simple
|
||||
but very useful check that the data is as expected.
|
||||
</para>
|
||||
|
||||
@ -602,7 +602,7 @@ you from moving a binary file across machines).
|
||||
<para>
|
||||
If OIDs are included in the dump, the OID field immediately follows the
|
||||
field-count word. It is a normal field except that it's not included
|
||||
in the field-count. In particular it has a typlen --- this will allow
|
||||
in the field-count. In particular it has a <structfield>typlen</> --- this will allow
|
||||
handling of 4-byte vs 8-byte OIDs without too much pain, and will allow
|
||||
OIDs to be shown as NULL if that ever proves desirable.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.20 2002/05/18 15:44:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.21 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -233,7 +233,7 @@ CREATE AGGREGATE
|
||||
If the state transition function is not strict, then it will be called
|
||||
unconditionally at each input value, and must deal with NULL inputs
|
||||
and NULL transition values for itself. This allows the aggregate
|
||||
author to have full control over the aggregate's handling of NULLs.
|
||||
author to have full control over the aggregate's handling of null values.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_conversion.sgml,v 1.3 2002/08/22 00:01:40 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/create_conversion.sgml,v 1.4 2002/09/21 18:32:54 petere Exp $ -->
|
||||
|
||||
<refentry id="SQL-CREATECONVERSION">
|
||||
<refmeta>
|
||||
@ -139,7 +139,7 @@ CREATE [DEFAULT] CONVERSION <replaceable>conversion_name</replaceable>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>
|
||||
To create a conversion from encoding UNICODE to LATIN1 using myfunc:
|
||||
To create a conversion from encoding UNICODE to LATIN1 using <function>myfunc</>:
|
||||
<programlisting>
|
||||
CREATE CONVERSION myconv FOR 'UNICODE' TO 'LATIN1' FROM myfunc;
|
||||
</programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.28 2002/06/17 05:40:32 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.29 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -114,7 +114,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
||||
<term><computeroutput>ERROR: user '<replaceable class="parameter">username</replaceable>' is not allowed to create/drop databases</computeroutput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
You must have the special CREATEDB privilege to create databases.
|
||||
You must have the special <literal>CREATEDB</> privilege to create databases.
|
||||
See <xref linkend="SQL-CREATEUSER" endterm="SQL-CREATEUSER-title">.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -186,7 +186,7 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
||||
Normally, the creator becomes the owner of the new database.
|
||||
Superusers can create databases owned by other users using the
|
||||
<option>OWNER</> clause. They can even create databases owned by
|
||||
users with no special privileges. Non-superusers with CREATEDB
|
||||
users with no special privileges. Non-superusers with <literal>CREATEDB</>
|
||||
privilege can only create databases owned by themselves.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.42 2002/08/22 00:01:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_function.sgml,v 1.43 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<refentry id="SQL-CREATEFUNCTION">
|
||||
@ -77,7 +77,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
|
||||
Depending on the implementation language it may also be allowed
|
||||
to specify <quote>pseudo-types</> such as <type>cstring</>.
|
||||
Pseudo-types indicate that the actual argument type is either
|
||||
incompletely specified, or outside the set of ordinary SQL datatypes.
|
||||
incompletely specified, or outside the set of ordinary SQL data types.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -171,7 +171,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
|
||||
<literal>CALLED ON NULL INPUT</literal> (the default) indicates
|
||||
that the function will be called normally when some of its
|
||||
arguments are null. It is then the function author's
|
||||
responsibility to check for NULLs if necessary and respond
|
||||
responsibility to check for null values if necessary and respond
|
||||
appropriately.
|
||||
</para>
|
||||
|
||||
@ -247,7 +247,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>isStrict</term>
|
||||
<term><literal>isStrict</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Equivalent to <literal>STRICT</literal> or <literal>RETURNS NULL ON NULL INPUT</literal>
|
||||
@ -256,7 +256,7 @@ CREATE [ OR REPLACE ] FUNCTION <replaceable class="parameter">name</replaceable>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>isCachable</term>
|
||||
<term><literal>isCachable</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>isCachable</literal> is an obsolete equivalent of
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.36 2002/08/13 20:40:43 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.37 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -266,7 +266,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
<para>
|
||||
The expression used in the <command>WHERE</command> clause may refer
|
||||
only to columns of the underlying table (but it can use all columns,
|
||||
not only the one(s) being indexed). Presently, sub-SELECTs and
|
||||
not only the one(s) being indexed). Presently, subqueries and
|
||||
aggregate expressions are also forbidden in <command>WHERE</command>.
|
||||
</para>
|
||||
|
||||
@ -331,7 +331,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
</para>
|
||||
<para>
|
||||
Testing has shown PostgreSQL's hash indexes to be similar or slower
|
||||
than btree indexes, and the index size and build time for hash
|
||||
than B-tree indexes, and the index size and build time for hash
|
||||
indexes is much worse. Hash indexes also suffer poor performance
|
||||
under high concurrency. For these reasons, hash index use is
|
||||
discouraged.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.2 2002/08/22 00:01:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.3 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -52,8 +52,8 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<listitem>
|
||||
<para>
|
||||
If present, the operator class will become the default index
|
||||
operator class for its datatype. At most one operator class
|
||||
can be the default for a specific datatype and access method.
|
||||
operator class for its data type. At most one operator class
|
||||
can be the default for a specific data type and access method.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -61,7 +61,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<term><replaceable class="parameter">data_type</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The column datatype that this operator class is for.
|
||||
The column data type that this operator class is for.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -95,10 +95,10 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<term><replaceable class="parameter">type</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The input datatype(s) of an operator, or <literal>NONE</> to
|
||||
signify a left-unary or right-unary operator. The input datatypes
|
||||
The input data type(s) of an operator, or <literal>NONE</> to
|
||||
signify a left-unary or right-unary operator. The input data types
|
||||
may be omitted in the normal case where they are the same as the
|
||||
operator class's datatype.
|
||||
operator class's data type.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -135,7 +135,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<term><replaceable class="parameter">parameter_types</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The parameter datatype(s) of the function.
|
||||
The parameter data type(s) of the function.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -143,8 +143,8 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
<term><replaceable class="parameter">storage_type</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The datatype actually stored in the index. Normally this is the
|
||||
same as the column datatype, but some index access methods (only
|
||||
The data type actually stored in the index. Normally this is the
|
||||
same as the column data type, but some index access methods (only
|
||||
GIST at this writing) allow it to be different. The
|
||||
<literal>STORAGE</> clause must be omitted unless the index access
|
||||
method allows a different type to be used.
|
||||
@ -191,9 +191,9 @@ CREATE OPERATOR CLASS
|
||||
<replaceable class="parameter">name</replaceable>.
|
||||
</para>
|
||||
<para>
|
||||
An operator class defines how a particular datatype can be used with
|
||||
An operator class defines how a particular data type can be used with
|
||||
an index. The operator class specifies that certain operators will fill
|
||||
particular roles or <quote>strategies</> for this datatype and this
|
||||
particular roles or <quote>strategies</> for this data type and this
|
||||
access method. The operator class also specifies the support procedures to
|
||||
be used by
|
||||
the index access method when the operator class is selected for an
|
||||
@ -210,7 +210,7 @@ CREATE OPERATOR CLASS
|
||||
</para>
|
||||
<para>
|
||||
The user who defines an operator class becomes its owner. The user
|
||||
must own the datatype for which the operator class is being defined,
|
||||
must own the data type for which the operator class is being defined,
|
||||
and must have execute permission for all referenced operators and functions.
|
||||
</para>
|
||||
|
||||
@ -248,7 +248,7 @@ CREATE OPERATOR CLASS
|
||||
</title>
|
||||
<para>
|
||||
The following example command defines a GiST index operator class
|
||||
for datatype <literal>_int4</> (array of int4). See
|
||||
for data type <literal>_int4</> (array of int4). See
|
||||
<filename>contrib/intarray/</> for the complete example.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.31 2002/08/23 02:54:18 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.32 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -268,10 +268,10 @@ CREATE OPERATOR
|
||||
are always equivalent.
|
||||
</para>
|
||||
<para>
|
||||
At least one of LEFTARG and RIGHTARG must be defined. For
|
||||
At least one of <literal>LEFTARG</> and <literal>RIGHTARG</> must be defined. For
|
||||
binary operators, both should be defined. For right unary
|
||||
operators, only LEFTARG should be defined, while for left
|
||||
unary operators only RIGHTARG should be defined.
|
||||
operators, only <literal>LEFTARG</> should be defined, while for left
|
||||
unary operators only <literal>RIGHTARG</> should be defined.
|
||||
</para>
|
||||
<para>
|
||||
The
|
||||
@ -335,39 +335,43 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
it also works to just have both operators refer to each other.)
|
||||
</para>
|
||||
<para>
|
||||
The HASHES, MERGES, SORT1, SORT2, LTCMP, and GTCMP options are present to
|
||||
support the query optimizer in performing joins.
|
||||
<productname>PostgreSQL</productname> can always evaluate a join (i.e.,
|
||||
processing a clause with two tuple variables separated by an operator that
|
||||
returns a <type>boolean</type>) by iterative substitution [WONG76]. In
|
||||
addition, <productname>PostgreSQL</productname> can use a hash-join
|
||||
algorithm along the lines of [SHAP86]; however, it must know whether this
|
||||
strategy is applicable. The current hash-join algorithm is only correct
|
||||
for operators that represent equality tests; furthermore, equality of the
|
||||
data type must mean bitwise equality of the representation of the type.
|
||||
(For example, a data type that contains unused bits that don't matter for
|
||||
equality tests could not be hash-joined.) The HASHES flag indicates to the
|
||||
query optimizer that a hash join may safely be used with this
|
||||
operator.
|
||||
The <literal>HASHES</>, <literal>MERGES</>, <literal>SORT1</>,
|
||||
<literal>SORT2</>, <literal>LTCMP</>, and <literal>GTCMP</> options
|
||||
are present to support the query optimizer in performing joins.
|
||||
<productname>PostgreSQL</productname> can always evaluate a join
|
||||
(i.e., processing a clause with two tuple variables separated by an
|
||||
operator that returns a <type>boolean</type>) by iterative
|
||||
substitution <!--[WONG76]-->. In addition,
|
||||
<productname>PostgreSQL</productname> can use a hash-join algorithm
|
||||
<!--along the lines of [SHAP86]-->; however, it must know whether this
|
||||
strategy is applicable. The current hash-join algorithm is only
|
||||
correct for operators that represent equality tests; furthermore,
|
||||
equality of the data type must mean bitwise equality of the
|
||||
representation of the type. (For example, a data type that
|
||||
contains unused bits that don't matter for equality tests could not
|
||||
be hash-joined.) The <literal>HASHES</> flag indicates to the query optimizer
|
||||
that a hash join may safely be used with this operator.
|
||||
</para>
|
||||
<para>
|
||||
Similarly, the MERGES flag indicates whether merge-sort is a usable join
|
||||
strategy for this operator. A merge join requires that the two input
|
||||
datatypes have consistent orderings, and that the mergejoin operator
|
||||
behave like equality with respect to that ordering. For example, it is
|
||||
possible to merge-join equality between an integer and a float variable by
|
||||
sorting both inputs in ordinary
|
||||
numeric order. Execution of a merge join requires that the system be
|
||||
able to identify four operators related to the mergejoin equality operator:
|
||||
less-than comparison for the left input datatype,
|
||||
less-than comparison for the right input datatype,
|
||||
less-than comparison between the two datatypes, and
|
||||
greater-than comparison between the two datatypes. It is possible to
|
||||
specify these by name, as the SORT1, SORT2, LTCMP, and GTCMP options
|
||||
respectively. The system will fill in the default names <literal><</>,
|
||||
<literal><</>, <literal><</>, <literal>></> respectively if
|
||||
any of these are omitted when MERGES is specified. Also, MERGES will
|
||||
be assumed to be implied if any of these four operator options appear.
|
||||
Similarly, the <literal>MERGES</> flag indicates whether merge-sort
|
||||
is a usable join strategy for this operator. A merge join requires
|
||||
that the two input data types have consistent orderings, and that
|
||||
the merge-join operator behave like equality with respect to that
|
||||
ordering. For example, it is possible to merge-join equality
|
||||
between an integer and a float variable by sorting both inputs in
|
||||
ordinary numeric order. Execution of a merge join requires that
|
||||
the system be able to identify four operators related to the
|
||||
merge-join equality operator: less-than comparison for the left
|
||||
input data type, less-than comparison for the right input data
|
||||
type, less-than comparison between the two data types, and
|
||||
greater-than comparison between the two data types. It is possible
|
||||
to specify these by name, as the <literal>SORT1</>,
|
||||
<literal>SORT2</>, <literal>LTCMP</>, and <literal>GTCMP</> options
|
||||
respectively. The system will fill in the default names
|
||||
<literal><</>, <literal><</>, <literal><</>,
|
||||
<literal>></> respectively if any of these are omitted when
|
||||
<literal>MERGES</> is specified. Also, <literal>MERGES</> will be
|
||||
assumed to be implied if any of these four operator options appear.
|
||||
</para>
|
||||
<para>
|
||||
If other join strategies are found to be practical,
|
||||
@ -380,14 +384,15 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
be worth the complexity involved.
|
||||
</para>
|
||||
<para>
|
||||
The RESTRICT and JOIN options assist the query optimizer in estimating
|
||||
result sizes. If a clause of the form:
|
||||
<programlisting>
|
||||
MYBOXES.description <<< box '((0,0), (1,1))'
|
||||
</programlisting>
|
||||
The <literal>RESTRICT</> and <literal>JOIN</> options assist the
|
||||
query optimizer in estimating result sizes. If a clause of the
|
||||
form:
|
||||
<programlisting>
|
||||
myboxes.description <<< box '((0,0), (1,1))'
|
||||
</programlisting>
|
||||
is present in the qualification,
|
||||
then <productname>PostgreSQL</productname> may have to
|
||||
estimate the fraction of the instances in MYBOXES that
|
||||
estimate the fraction of the instances in <literal>myboxes</> that
|
||||
satisfy the clause. The function
|
||||
<replaceable class="parameter">res_proc</replaceable>
|
||||
must be a registered function (meaning it is already defined using
|
||||
@ -400,7 +405,7 @@ MYBOXES.description <<< box '((0,0), (1,1))'
|
||||
<para>
|
||||
Similarly, when the operands of the operator both contain
|
||||
instance variables, the query optimizer must estimate the
|
||||
size of the resulting join. The function join_proc will
|
||||
size of the resulting join. The function <function>join_proc</> will
|
||||
return another floating-point number which will be multiplied
|
||||
by the cardinalities of the two tables involved to
|
||||
compute the expected result size.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_schema.sgml,v 1.2 2002/05/18 15:44:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_schema.sgml,v 1.3 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -33,7 +33,7 @@ CREATE SCHEMA AUTHORIZATION <replaceable class="parameter">username</replaceable
|
||||
<term><replaceable class="parameter">schemaname</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of a schema to be created. If this is omitted, the username
|
||||
The name of a schema to be created. If this is omitted, the user name
|
||||
is used as the schema name.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -111,7 +111,7 @@ ERROR: namespace "<replaceable class="parameter">schemaname</replaceable>" alre
|
||||
|
||||
<para>
|
||||
A schema is essentially a namespace:
|
||||
it contains named objects (tables, datatypes, functions, and operators)
|
||||
it contains named objects (tables, data types, functions, and operators)
|
||||
whose names may duplicate those of other objects existing in other
|
||||
schemas. Named objects are accessed either by <quote>qualifying</>
|
||||
their names with the schema name as a prefix, or by setting a search
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.34 2002/08/29 00:17:01 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.35 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -208,7 +208,7 @@ CREATE TYPE
|
||||
specified schema. Otherwise it is created in the current schema (the one
|
||||
at the front of the search path; see <literal>CURRENT_SCHEMA()</>).
|
||||
The type name must be distinct from the name of any existing type or
|
||||
domain in the same schema. (Because tables have associated datatypes,
|
||||
domain in the same schema. (Because tables have associated data types,
|
||||
type names also must not conflict with table names in the same schema.)
|
||||
</para>
|
||||
|
||||
@ -231,10 +231,10 @@ CREATE TYPE
|
||||
<type>cstring</type>, <type>OID</type>, <type>int4</type>.
|
||||
(The first argument is the input text as a C string, the second
|
||||
argument is the element type in case this is an array type,
|
||||
and the third is the typmod of the destination column, if known.)
|
||||
It should return a value of the datatype itself.
|
||||
and the third is the <literal>typmod</> of the destination column, if known.)
|
||||
It should return a value of the data type itself.
|
||||
The output function may be
|
||||
declared as taking one argument of the new datatype, or as taking
|
||||
declared as taking one argument of the new data type, or as taking
|
||||
two arguments of which the second is type <type>OID</type>.
|
||||
(The second argument is again the array element type for array types.)
|
||||
The output function should return type <type>cstring</type>.
|
||||
@ -245,9 +245,9 @@ CREATE TYPE
|
||||
can be declared to have results or inputs of the new type, when they have
|
||||
to be created before the new type can be created. The answer is that the
|
||||
input function must be created first, then the output function, then the
|
||||
datatype.
|
||||
data type.
|
||||
<productname>PostgreSQL</productname> will first see the name of the new
|
||||
datatype as the return type of the input function. It will create a
|
||||
data type as the return type of the input function. It will create a
|
||||
<quote>shell</> type, which is simply a placeholder entry in
|
||||
<literal>pg_type</>, and link the input function definition to the shell
|
||||
type. Similarly the output function will be linked to the (now already
|
||||
@ -273,7 +273,7 @@ CREATE TYPE
|
||||
positive integer, or variable length, indicated by setting
|
||||
<replaceable class="parameter">internallength</replaceable>
|
||||
to <option>VARIABLE</option>. (Internally, this is represented
|
||||
by setting typlen to -1.) The internal representation of all
|
||||
by setting <literal>typlen</> to -1.) The internal representation of all
|
||||
variable-length types must start with an integer giving the total
|
||||
length of this value of the type.
|
||||
</para>
|
||||
@ -346,7 +346,7 @@ CREATE TYPE
|
||||
<para>
|
||||
The second form of <command>CREATE TYPE</command>
|
||||
creates a composite type.
|
||||
The composite type is specified by a list of column names and datatypes.
|
||||
The composite type is specified by a list of column names and data types.
|
||||
This is essentially the same as the row type
|
||||
of a table, but using <command>CREATE TYPE</command> avoids the need to
|
||||
create an actual table when all that is wanted is to define a type.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.19 2002/09/02 20:04:39 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_view.sgml,v 1.20 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -235,7 +235,7 @@ CREATE VIEW <replaceable class="parameter">view</replaceable> [ <replaceable cla
|
||||
<listitem>
|
||||
<para>
|
||||
This option is to do with updatable views.
|
||||
All INSERTs and UPDATEs on the view will be
|
||||
All <command>INSERT</> and <command>UPDATE</> commands on the view will be
|
||||
checked to ensure data satisfy the view-defining
|
||||
condition. If they do not, the update will be rejected.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createdb.sgml,v 1.28 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createdb.sgml,v 1.29 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -61,7 +61,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -72,7 +73,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or the local Unix domain socket file
|
||||
@ -82,7 +84,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U, --username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -91,7 +94,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W, --password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
@ -100,7 +104,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the queries that <application>createdb</application> generates
|
||||
@ -110,7 +115,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q, --quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
@ -119,7 +125,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-O, --owner <replaceable class="parameter">owner</replaceable></term>
|
||||
<term><option>-O <replaceable class="parameter">owner</replaceable></></term>
|
||||
<term><option>--owner <replaceable class="parameter">owner</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the database user who will own the new database.
|
||||
@ -128,7 +135,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-D, --location <replaceable class="parameter">datadir</replaceable></term>
|
||||
<term><option>-D <replaceable class="parameter">datadir</replaceable></></term>
|
||||
<term><option>--location <replaceable class="parameter">datadir</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the alternative location for the database. See also <xref
|
||||
@ -138,7 +146,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-T, --template <replaceable class="parameter">template</replaceable></term>
|
||||
<term><option>-T <replaceable class="parameter">template</replaceable></></term>
|
||||
<term><option>--template <replaceable class="parameter">template</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the template database from which to build this database.
|
||||
@ -147,7 +156,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-E, --encoding <replaceable class="parameter">encoding</replaceable></term>
|
||||
<term><option>-E <replaceable class="parameter">encoding</replaceable></></term>
|
||||
<term><option>--encoding <replaceable class="parameter">encoding</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the character encoding scheme to be used in this database.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createlang.sgml,v 1.26 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createlang.sgml,v 1.27 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -69,7 +69,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-d, --dbname <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term><option>-d <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<term><option>--dbname <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies to which database the language should be added.
|
||||
@ -80,7 +81,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Displays SQL commands as they are executed.
|
||||
@ -89,7 +91,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-l, --list</term>
|
||||
<term><option>-l</></term>
|
||||
<term><option>--list</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Shows a list of already installed languages in the target database
|
||||
@ -99,7 +102,7 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--L <replaceable class="parameter">directory</replaceable></term>
|
||||
<term><option>-L <replaceable class="parameter">directory</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the directory in which the language interpreter is
|
||||
@ -118,7 +121,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -130,7 +134,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -141,7 +146,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U, --username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -150,7 +156,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W, --password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.27 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/createuser.sgml,v 1.28 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -39,7 +39,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
Being a superuser also implies the ability to bypass access permission
|
||||
checks within the database, so superuser-dom should not be granted lightly.
|
||||
checks within the database, so superuserdom should not be granted lightly.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -64,7 +64,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -76,7 +77,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -87,7 +89,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the queries that <application>createuser</application> generates
|
||||
@ -97,7 +100,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q, --quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
@ -106,7 +110,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-d, --createdb</term>
|
||||
<term><option>-d</></term>
|
||||
<term><option>--createdb</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The new user is allowed to create databases.
|
||||
@ -115,7 +120,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-D, --no-createdb</term>
|
||||
<term><option>-D</></term>
|
||||
<term><option>--no-createdb</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The new user is not allowed to create databases.
|
||||
@ -124,7 +130,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-a, --adduser</term>
|
||||
<term><option>-a</></term>
|
||||
<term><option>--adduser</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The new user is allowed to create other users.
|
||||
@ -135,7 +142,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-A, --no-adduser</term>
|
||||
<term><option>-A</></term>
|
||||
<term><option>--no-adduser</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The new user is not allowed to create other users (i.e.,
|
||||
@ -145,7 +153,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-P, --pwprompt</term>
|
||||
<term><option>-P</></term>
|
||||
<term><option>--pwprompt</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If given, <application>createuser</application> will issue a prompt for
|
||||
@ -156,7 +165,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-i, --sysid <replaceable class="parameter">uid</replaceable></term>
|
||||
<term><option>-i <replaceable class="parameter">uid</replaceable></></term>
|
||||
<term><option>--sysid <replaceable class="parameter">uid</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows you to pick a non-default user id for the new user. This is not
|
||||
@ -166,7 +176,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-E, --encrypted</term>
|
||||
<term><option>-E</></term>
|
||||
<term><option>--encrypted</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Encrypts the user's password stored in the database. If not
|
||||
@ -176,7 +187,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-N, --unencrypted</term>
|
||||
<term><option>-N</></term>
|
||||
<term><option>--unencrypted</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Does not encrypt the user's password stored in the database. If
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_conversion.sgml,v 1.2 2002/07/22 13:00:00 ishii Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_conversion.sgml,v 1.3 2002/09/21 18:32:54 petere Exp $ -->
|
||||
|
||||
<refentry id="SQL-DROPCONVERSION">
|
||||
<refmeta>
|
||||
@ -76,7 +76,7 @@ DROP CONVERSION <replaceable>conversion_name</replaceable>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>
|
||||
To drop the conversion named myname:
|
||||
To drop the conversion named <literal>myname</>:
|
||||
<programlisting>
|
||||
DROP CONVERSION myname;
|
||||
</programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_opclass.sgml,v 1.1 2002/07/29 22:14:10 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/drop_opclass.sgml,v 1.2 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -134,7 +134,7 @@ DROP OPERATOR CLASS
|
||||
Usage
|
||||
</title>
|
||||
<para>
|
||||
Remove btree operator class <literal>widget_ops</literal>:
|
||||
Remove B-tree operator class <literal>widget_ops</literal>:
|
||||
|
||||
<programlisting>
|
||||
DROP OPERATOR CLASS widget_ops USING btree;
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropdb.sgml,v 1.17 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropdb.sgml,v 1.18 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -54,7 +54,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -66,7 +67,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -77,7 +79,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U, --username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -86,7 +89,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W, --password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
@ -95,7 +99,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the queries that <application>dropdb</application> generates
|
||||
@ -105,7 +110,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q, --quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
@ -114,7 +120,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-i, --interactive</term>
|
||||
<term><option>-i</></term>
|
||||
<term><option>--interactive</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Issues a verification prompt before doing anything destructive.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/droplang.sgml,v 1.20 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/droplang.sgml,v 1.21 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -69,7 +69,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>[-d, --dbname] <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term><option><optional>-d</> <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<term><option><optional>--dbname</> <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies from which database the language should be removed.
|
||||
@ -80,7 +81,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Displays SQL commands as they are executed.
|
||||
@ -89,7 +91,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-l, --list</term>
|
||||
<term><option>-l</></term>
|
||||
<term><option>--list</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Shows a list of already installed languages in the target database
|
||||
@ -107,7 +110,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -119,7 +123,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -130,7 +135,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U, --username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -139,7 +145,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W, --password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.20 2002/08/10 16:57:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/dropuser.sgml,v 1.21 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -56,7 +56,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -68,7 +69,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -79,7 +81,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the queries that <application>dropuser</application> generates
|
||||
@ -89,7 +92,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q, --quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
@ -98,7 +102,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-i, --interactive</term>
|
||||
<term><option>-i</></term>
|
||||
<term><option>--interactive</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Prompt for confirmation before actually removing the user.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/initdb.sgml,v 1.21 2002/04/21 19:02:39 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/initdb.sgml,v 1.22 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -114,8 +114,8 @@ PostgreSQL documentation
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>--pgdata=<replaceable class="parameter">directory</replaceable></term>
|
||||
<term>-D <replaceable class="parameter">directory</replaceable></term>
|
||||
<term><option>--pgdata=<replaceable class="parameter">directory</replaceable></option></term>
|
||||
<term><option>-D <replaceable class="parameter">directory</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This option specifies the directory where the database system
|
||||
@ -130,23 +130,23 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--username=<replaceable class="parameter">username</replaceable></term>
|
||||
<term>-U <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>--username=<replaceable class="parameter">username</replaceable></option></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Selects the user name of the database superuser. This defaults
|
||||
to the name of the effective user running
|
||||
<command>initdb</command>. It is really not important what the
|
||||
superuser's name is, but one might choose to keep the
|
||||
customary name <quote>postgres</quote>, even if the operating
|
||||
customary name <systemitem>postgres</systemitem>, even if the operating
|
||||
system user's name is different.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--pwprompt</term>
|
||||
<term>-W</term>
|
||||
<term><option>--pwprompt</option></term>
|
||||
<term><option>-W</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Makes <command>initdb</command> prompt for a password
|
||||
@ -159,8 +159,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--encoding=<replaceable class="parameter">encoding</replaceable></term>
|
||||
<term>-E <replaceable class="parameter">encoding</replaceable></term>
|
||||
<term><option>--encoding=<replaceable class="parameter">encoding</replaceable></option></term>
|
||||
<term><option>-E <replaceable class="parameter">encoding</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Selects the encoding of the template database. This will also
|
||||
@ -173,7 +173,7 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--locale=<replaceable>locale</replaceable></term>
|
||||
<term><option>--locale=<replaceable>locale</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the default locale for the database cluster. If this
|
||||
@ -184,12 +184,12 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--lc-collate=<replaceable>locale</replaceable></term>
|
||||
<term>--lc-ctype=<replaceable>locale</replaceable></term>
|
||||
<term>--lc-messages=<replaceable>locale</replaceable></term>
|
||||
<term>--lc-monetary=<replaceable>locale</replaceable></term>
|
||||
<term>--lc-numeric=<replaceable>locale</replaceable></term>
|
||||
<term>--lc-time=<replaceable>locale</replaceable></term>
|
||||
<term><option>--lc-collate=<replaceable>locale</replaceable></option></term>
|
||||
<term><option>--lc-ctype=<replaceable>locale</replaceable></option></term>
|
||||
<term><option>--lc-messages=<replaceable>locale</replaceable></option></term>
|
||||
<term><option>--lc-monetary=<replaceable>locale</replaceable></option></term>
|
||||
<term><option>--lc-numeric=<replaceable>locale</replaceable></option></term>
|
||||
<term><option>--lc-time=<replaceable>locale</replaceable></option></term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
@ -206,7 +206,7 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-L <replaceable class="parameter">directory</replaceable></term>
|
||||
<term><option>-L <replaceable class="parameter">directory</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies where <command>initdb</command> should find
|
||||
@ -218,8 +218,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--noclean</term>
|
||||
<term>-n</term>
|
||||
<term><option>-n</option></term>
|
||||
<term><option>--noclean</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
By default, when <command>initdb</command>
|
||||
@ -232,8 +232,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>--debug</term>
|
||||
<term>-d</term>
|
||||
<term><option>-d</option></term>
|
||||
<term><option>--debug</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print debugging output from the bootstrap backend and a few other
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.18 2002/04/24 02:31:30 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/insert.sgml,v 1.19 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -55,8 +55,8 @@ INSERT INTO <replaceable class="PARAMETER">table</replaceable> [ ( <replaceable
|
||||
<term>DEFAULT VALUES</term>
|
||||
<listitem>
|
||||
<para>
|
||||
All columns will be filled by NULLs or by values specified
|
||||
when the table was created using DEFAULT clauses.
|
||||
All columns will be filled by null values or by values specified
|
||||
when the table was created using <literal>DEFAULT</> clauses.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/listen.sgml,v 1.14 2002/08/13 20:40:43 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/listen.sgml,v 1.15 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -115,12 +115,12 @@ WARNING: Async_Listen: We are already listening on <replaceable class="PARAMETE
|
||||
<para>
|
||||
The method a frontend application must use to detect notify events depends on
|
||||
which <productname>PostgreSQL</productname> application programming interface it
|
||||
uses. With the basic libpq library, the application issues
|
||||
uses. With the <application>libpq</> library, the application issues
|
||||
<command>LISTEN</command> as an ordinary SQL command, and then must
|
||||
periodically call the routine <function>PQnotifies</function> to find out
|
||||
whether any notify events have been received. Other interfaces such as
|
||||
libpgtcl provide higher-level methods for handling notify events; indeed,
|
||||
with libpgtcl the application programmer should not even issue
|
||||
<application>libpgtcl</> provide higher-level methods for handling notify events; indeed,
|
||||
with <application>libpgtcl</> the application programmer should not even issue
|
||||
<command>LISTEN</command> or <command>UNLISTEN</command> directly. See the
|
||||
documentation for the library you are using for more details.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.33 2002/05/30 20:45:18 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/lock.sgml,v 1.34 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -118,7 +118,7 @@ where <replaceable class="PARAMETER">lockmode</replaceable> is one of:
|
||||
Conflicts with SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
|
||||
EXCLUSIVE and
|
||||
ACCESS EXCLUSIVE modes. This mode protects a table against
|
||||
concurrent schema changes and VACUUMs.
|
||||
concurrent schema changes and <command>VACUUM</> runs.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
@ -289,8 +289,8 @@ ERROR <replaceable class="PARAMETER">name</replaceable>: Table does not exist.
|
||||
To achieve a similar effect when running a transaction
|
||||
at the SERIALIZABLE isolation level, you have to execute the
|
||||
<command>LOCK TABLE</>
|
||||
statement before executing any DML statement. A serializable
|
||||
transaction's view of data will be frozen when its first DML statement
|
||||
statement before executing any <acronym>DML</> statement. A serializable
|
||||
transaction's view of data will be frozen when its first <acronym>DML</> statement
|
||||
begins. A later <command>LOCK</> will still prevent concurrent writes
|
||||
--- but it
|
||||
won't ensure that what the transaction reads corresponds to the latest
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/notify.sgml,v 1.18 2002/08/13 20:40:44 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/notify.sgml,v 1.19 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -95,7 +95,7 @@ NOTIFY
|
||||
</para>
|
||||
<para>
|
||||
The information passed to the frontend for a notify event includes the notify
|
||||
condition name and the notifying backend process's PID. It is up to the
|
||||
condition name and the notifying backend process's <acronym>PID</>. It is up to the
|
||||
database designer to define the condition names that will be used in a given
|
||||
database and what each one means.
|
||||
</para>
|
||||
@ -109,7 +109,7 @@ NOTIFY
|
||||
</para>
|
||||
<para>
|
||||
<command>NOTIFY</command> provides a simple form of signal or
|
||||
IPC (interprocess communication) mechanism for a collection of processes
|
||||
<acronym>IPC</> (interprocess communication) mechanism for a collection of processes
|
||||
accessing the same <productname>PostgreSQL</productname> database.
|
||||
Higher-level mechanisms can be built by using tables in the database to
|
||||
pass additional data (beyond a mere condition name) from notifier to
|
||||
@ -158,8 +158,8 @@ NOTIFY
|
||||
re-reading a database table to find the same updates that that frontend just
|
||||
wrote out. In <productname>PostgreSQL</productname> 6.4 and later, it is
|
||||
possible to avoid such extra work by noticing whether the notifying backend
|
||||
process's PID (supplied in the notify event message) is the same as one's own
|
||||
backend's PID (available from libpq). When they are the same, the notify
|
||||
process's <acronym>PID</> (supplied in the notify event message) is the same as one's own
|
||||
backend's <acronym>PID</> (available from <application>libpq</>). When they are the same, the notify
|
||||
event is one's own work bouncing back, and can be ignored. (Despite what was
|
||||
said in the preceding paragraph, this is a safe technique.
|
||||
<productname>PostgreSQL</productname> keeps self-notifies separate from notifies
|
||||
@ -191,7 +191,7 @@ NOTIFY
|
||||
</para>
|
||||
<para>
|
||||
In <productname>PostgreSQL</productname> releases prior to 6.4, the backend
|
||||
PID delivered in a notify message was always the PID of the frontend's own
|
||||
<acronym>PID</> delivered in a notify message was always the <acronym>PID</> of the frontend's own
|
||||
backend. So it was not possible to distinguish one's own notifies from other
|
||||
clients' notifies in those earlier releases.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.15 2002/07/28 15:22:20 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.16 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -148,7 +148,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
Append the server log output to
|
||||
<replaceable>filename</replaceable>. If the file does not
|
||||
exist, it is created. The umask is set to 077, so access to
|
||||
exist, it is created. The <systemitem>umask</> is set to 077, so access to
|
||||
the log file from other users is disallowed by default.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.31 2002/07/28 15:22:21 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.32 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -146,7 +146,7 @@ PostgreSQL documentation
|
||||
Disables <function>fsync</function> calls for performance
|
||||
improvement, at the risk of data corruption in event of a
|
||||
system crash. This parameter corresponds to setting
|
||||
fsync=false in postgresql.conf. Read the detailed
|
||||
<literal>fsync=false</> in <filename>postgresql.conf</>. Read the detailed
|
||||
documentation before using this!
|
||||
</para>
|
||||
<para>
|
||||
@ -176,7 +176,7 @@ PostgreSQL documentation
|
||||
Allows clients to connect via TCP/IP (Internet domain)
|
||||
connections. Without this option, only local Unix domain
|
||||
socket connections are accepted. This option corresponds
|
||||
to setting tcpip_socket=true in postgresql.conf.
|
||||
to setting <literal>tcpip_socket=true</> in <filename>postgresql.conf</>.
|
||||
</para>
|
||||
<para>
|
||||
<option>--tcpip_socket=false</option> has the opposite
|
||||
@ -350,7 +350,7 @@ PostgreSQL documentation
|
||||
<listitem>
|
||||
<para>
|
||||
Default character encoding used by clients. (The clients may
|
||||
override this invidiually.) This value can also be set in the
|
||||
override this individually.) This value can also be set in the
|
||||
configuration file.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -382,7 +382,7 @@ PostgreSQL documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default port (preferrably set in the configuration file)
|
||||
Default port (preferably set in the configuration file)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -520,10 +520,11 @@ StreamServerPort: cannot bind to port
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <option>--</> options will not work on FreeBSD or OpenBSD.
|
||||
The <option>--</> options will not work on <systemitem
|
||||
class="osname">FreeBSD</> or <systemitem class="osname">OpenBSD</>.
|
||||
Use <option>-c</> instead. This is a bug in the affected operating
|
||||
systems; a future release of <productname>PostgreSQL</productname> will
|
||||
provide a workaround if this is not fixed.
|
||||
systems; a future release of <productname>PostgreSQL</productname>
|
||||
will provide a workaround if this is not fixed.
|
||||
</para>
|
||||
|
||||
</refsect1>
|
||||
@ -547,7 +548,7 @@ StreamServerPort: cannot bind to port
|
||||
</screen>
|
||||
This command will start up <application>postmaster</application>
|
||||
communicating through the port 1234. In order to connect to this
|
||||
<application>postmaster</application> using psql, you would need to
|
||||
<application>postmaster</application> using <application>psql</>, you would need to
|
||||
run it as
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>psql -p 1234</userinput>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.75 2002/09/18 20:09:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.76 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -51,19 +51,21 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-a, --echo-all</term>
|
||||
<term><option>-a</></term>
|
||||
<term><option>--echo-all</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print all the lines to the screen as they are read. This is more
|
||||
useful for script processing rather than interactive mode. This is
|
||||
equivalent to setting the variable <envar>ECHO</envar> to
|
||||
equivalent to setting the variable <varname>ECHO</varname> to
|
||||
<literal>all</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-A, --no-align</term>
|
||||
<term><option>-A</></term>
|
||||
<term><option>--no-align</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Switches to unaligned output mode. (The default output mode is
|
||||
@ -73,7 +75,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-c, --command <replaceable class="parameter">query</replaceable></term>
|
||||
<term><option>-c <replaceable class="parameter">query</replaceable></></term>
|
||||
<term><option>--command <replaceable class="parameter">query</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies that <application>psql</application> is to execute one
|
||||
@ -82,7 +85,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
<para>
|
||||
<replaceable class="parameter">query</replaceable> must be either
|
||||
a query string that is completely parseable by the backend (i.e.,
|
||||
a query string that is completely parsable by the backend (i.e.,
|
||||
it contains no <application>psql</application> specific features),
|
||||
or it is a single backslash command. Thus you cannot mix
|
||||
<acronym>SQL</acronym> and <application>psql</application>
|
||||
@ -94,7 +97,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-d, --dbname <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term><option>-d <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<term><option>--dbname <replaceable class="parameter">dbname</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the name of the database to connect to. This is
|
||||
@ -106,31 +110,34 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e, --echo-queries</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo-queries</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Show all queries that are sent to the backend. This is equivalent
|
||||
to setting the variable <envar>ECHO</envar> to
|
||||
to setting the variable <varname>ECHO</varname> to
|
||||
<literal>queries</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-E, --echo-hidden</term>
|
||||
<term><option>-E</></term>
|
||||
<term><option>--echo-hidden</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echoes the actual queries generated by \d and other backslash
|
||||
commands. You can use this if you wish to include similar
|
||||
functionality into your own programs. This is equivalent to
|
||||
setting the variable <envar>ECHO_HIDDEN</envar> from within
|
||||
setting the variable <varname>ECHO_HIDDEN</varname> from within
|
||||
<application>psql</application>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-f, --file <replaceable class="parameter">filename</replaceable></term>
|
||||
<term><option>-f <replaceable class="parameter">filename</replaceable></></term>
|
||||
<term><option>--file <replaceable class="parameter">filename</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use the file <replaceable class="parameter">filename</replaceable>
|
||||
@ -161,7 +168,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-F, --field-separator <replaceable class="parameter">separator</replaceable></term>
|
||||
<term><option>-F <replaceable class="parameter">separator</replaceable></></term>
|
||||
<term><option>--field-separator <replaceable class="parameter">separator</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <replaceable class="parameter">separator</replaceable> as the
|
||||
@ -172,19 +180,21 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-h, --host <replaceable class="parameter">hostname</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">hostname</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">hostname</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
<application>postmaster</application> is running. If host begins
|
||||
with a slash, it is used as the directory for the unix domain
|
||||
with a slash, it is used as the directory for the Unix-domain
|
||||
socket.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-H, --html</term>
|
||||
<term><option>-H</></term>
|
||||
<term><option>--html</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Turns on <acronym>HTML</acronym> tabular output. This is
|
||||
@ -195,7 +205,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-l, --list</term>
|
||||
<term><option>-l</></term>
|
||||
<term><option>--list</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Lists all available databases, then exits. Other non-connection
|
||||
@ -206,7 +217,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-o, --output <replaceable class="parameter">filename</replaceable></term>
|
||||
<term><option>-o <replaceable class="parameter">filename</replaceable></></term>
|
||||
<term><option>--output <replaceable class="parameter">filename</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Put all query output into file <replaceable
|
||||
@ -217,7 +229,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p, --port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the TCP/IP port or, by omission, the local Unix domain
|
||||
@ -231,7 +244,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-P, --pset <replaceable class="parameter">assignment</replaceable></term>
|
||||
<term><option>-P <replaceable class="parameter">assignment</replaceable></></term>
|
||||
<term><option>--pset <replaceable class="parameter">assignment</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows you to specify printing options in the style of
|
||||
@ -244,7 +258,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies that <application>psql</application> should do its work
|
||||
@ -252,13 +267,14 @@ PostgreSQL documentation
|
||||
informational output. If this option is used, none of this
|
||||
happens. This is useful with the <option>-c</option> option.
|
||||
Within <application>psql</application> you can also set the
|
||||
<envar>QUIET</envar> variable to achieve the same effect.
|
||||
<varname>QUIET</varname> variable to achieve the same effect.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-R, --record-separator <replaceable class="parameter">separator</replaceable></term>
|
||||
<term><option>-R <replaceable class="parameter">separator</replaceable></></term>
|
||||
<term><option>--record-separator <replaceable class="parameter">separator</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <replaceable class="parameter">separator</replaceable> as the
|
||||
@ -269,7 +285,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-s, --single-step</term>
|
||||
<term><option>-s</></term>
|
||||
<term><option>--single-step</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Run in single-step mode. That means the user is prompted before
|
||||
@ -280,7 +297,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-S, --single-line</term>
|
||||
<term><option>-S</></term>
|
||||
<term><option>--single-line</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Runs in single-line mode where a newline terminates a query, as a
|
||||
@ -299,7 +317,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-t, --tuples-only</term>
|
||||
<term><option>-t</></term>
|
||||
<term><option>--tuples-only</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Turn off printing of column names and result row count footers,
|
||||
@ -310,7 +329,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-T, --table-attr <replaceable class="parameter">table_options</replaceable></term>
|
||||
<term><option>-T <replaceable class="parameter">table_options</replaceable></></term>
|
||||
<term><option>--table-attr <replaceable class="parameter">table_options</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows you to specify options to be placed within the
|
||||
@ -321,7 +341,7 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-u</term>
|
||||
<term><option>-u</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Makes <application>psql</application> prompt for the user name and
|
||||
@ -339,7 +359,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U, --username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Connects to the database as the user <replaceable
|
||||
@ -350,7 +371,9 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-v, --variable, --set <replaceable class="parameter">assignment</replaceable></term>
|
||||
<term><option>-v <replaceable class="parameter">assignment</replaceable></></term>
|
||||
<term><option>--set <replaceable class="parameter">assignment</replaceable></></term>
|
||||
<term><option>--variable <replaceable class="parameter">assignment</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Performs a variable assignment, like the <command>\set</command>
|
||||
@ -365,7 +388,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-V, --version</term>
|
||||
<term><option>-V</></term>
|
||||
<term><option>--version</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Shows the <application>psql</application> version.
|
||||
@ -374,7 +398,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W, --password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Requests that <application>psql</application> should prompt for a
|
||||
@ -396,7 +421,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-x, --expanded</term>
|
||||
<term><option>-x</></term>
|
||||
<term><option>--expanded</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Turns on extended row format mode. This is equivalent to the
|
||||
@ -406,7 +432,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-X, --no-psqlrc</term>
|
||||
<term><option>-X,</></term>
|
||||
<term><option>--no-psqlrc</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not read the start-up file <filename>~/.psqlrc</filename>.
|
||||
@ -415,7 +442,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-?, --help</term>
|
||||
<term><option>-?</></term>
|
||||
<term><option>--help</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Shows help about <application>psql</application> command line
|
||||
@ -435,7 +463,7 @@ PostgreSQL documentation
|
||||
finished normally, 1 if a fatal error of its own (out of memory,
|
||||
file not found) occurs, 2 if the connection to the backend went bad
|
||||
and the session is not interactive, and 3 if an error occurred in a
|
||||
script and the variable <envar>ON_ERROR_STOP</envar> was set.
|
||||
script and the variable <varname>ON_ERROR_STOP</varname> was set.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
@ -458,7 +486,7 @@ PostgreSQL documentation
|
||||
not belong to any option it will be interpreted as the database name
|
||||
(or the user name, if the database name is also given). Not all
|
||||
these options are required, defaults do apply. If you omit the host
|
||||
name psql will connect via a Unix domain socket to a server on the
|
||||
name, <application>psql</> will connect via a Unix domain socket to a server on the
|
||||
local host. The default port number is compile-time determined.
|
||||
Since the database server uses the same default, you will not have
|
||||
to specify the port in most cases. The default user name is your
|
||||
@ -556,11 +584,11 @@ testdb=>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Arguments that are quoted in <quote>backticks</quote>
|
||||
(<literal>`</literal>) are taken as a command line that is passed to
|
||||
the shell. The output of the command (with any trailing newline
|
||||
removed) is taken as the argument value. The above escape sequences
|
||||
also apply in backticks.
|
||||
Arguments that are enclosed in backquotes (<literal>`</literal>)
|
||||
are taken as a command line that is passed to the shell. The
|
||||
output of the command (with any trailing newline removed) is taken
|
||||
as the argument value. The above escape sequences also apply in
|
||||
backquotes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -665,13 +693,13 @@ testdb=>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><literal>\copy</literal> <replaceable class="parameter">table</replaceable>
|
||||
<term><literal>\copy <replaceable class="parameter">table</replaceable>
|
||||
{ <literal>from</literal> | <literal>to</literal> }
|
||||
<replaceable class="parameter">filename</replaceable> | stdin | stdout
|
||||
[ <literal>with</literal> ]
|
||||
[ <literal>oids</literal> ]
|
||||
[ <literal>delimiter [as] </literal> '<replaceable class="parameter">character</replaceable>' ]
|
||||
[ <literal>null [as] </literal> '<replaceable class="parameter">string</replaceable>' ]
|
||||
[ <literal>null [as] </literal> '<replaceable class="parameter">string</replaceable>' ]</literal>
|
||||
</term>
|
||||
|
||||
<listitem>
|
||||
@ -838,7 +866,7 @@ testdb=>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
To reduce clutter, <literal>\df</> does not show datatype I/O
|
||||
To reduce clutter, <literal>\df</> does not show data type I/O
|
||||
functions. This is implemented by ignoring functions that accept
|
||||
or return type <type>cstring</>.
|
||||
</para>
|
||||
@ -1087,7 +1115,7 @@ Tue Oct 26 21:40:57 CEST 1999
|
||||
<note>
|
||||
<para>
|
||||
If you want to see the lines on the screen as they are read you
|
||||
must set the variable <envar>ECHO</envar> to
|
||||
must set the variable <varname>ECHO</varname> to
|
||||
<literal>all</literal>.
|
||||
</para>
|
||||
</note>
|
||||
@ -1132,7 +1160,7 @@ Tue Oct 26 21:40:57 CEST 1999
|
||||
</tip>
|
||||
<note>
|
||||
<para>
|
||||
See the description of the <envar>LO_TRANSACTION</envar>
|
||||
See the description of the <varname>LO_TRANSACTION</varname>
|
||||
variable for important information concerning all large object
|
||||
operations.
|
||||
</para>
|
||||
@ -1169,7 +1197,7 @@ lo_import 152801
|
||||
|
||||
<note>
|
||||
<para>
|
||||
See the description of the <envar>LO_TRANSACTION</envar>
|
||||
See the description of the <varname>LO_TRANSACTION</varname>
|
||||
variable for important information concerning all large object
|
||||
operations.
|
||||
</para>
|
||||
@ -1206,7 +1234,7 @@ lo_import 152801
|
||||
</tip>
|
||||
<note>
|
||||
<para>
|
||||
See the description of the <envar>LO_TRANSACTION</envar>
|
||||
See the description of the <varname>LO_TRANSACTION</varname>
|
||||
variable for important information concerning all large object
|
||||
operations.
|
||||
</para>
|
||||
@ -1426,7 +1454,7 @@ lo_import 152801
|
||||
<term><literal>pager</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Toggles the use of a pager for query and psql help output. If the
|
||||
Toggles the use of a pager for query and <application>psql</> help output. If the
|
||||
environment variable <envar>PAGER</envar> is set, the output
|
||||
is piped to the specified program. Otherwise a platform-dependent default (such as
|
||||
<filename>more</filename>) is used.
|
||||
@ -1775,7 +1803,7 @@ bar
|
||||
such variables. A list of all specially treated variables follows.
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><envar>DBNAME</envar></term>
|
||||
<term><varname>DBNAME</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the database you are currently connected to. This is
|
||||
@ -1786,7 +1814,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>ECHO</envar></term>
|
||||
<term><varname>ECHO</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If set to <quote><literal>all</literal></quote>, all lines
|
||||
@ -1802,14 +1830,14 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>ECHO_HIDDEN</envar></term>
|
||||
<term><varname>ECHO_HIDDEN</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
When this variable is set and a backslash command queries the
|
||||
database, the query is first shown. This way you can study the
|
||||
<productname>PostgreSQL</productname> internals and provide
|
||||
similar functionality in your own programs. If you set the
|
||||
variable to the value <quote>noexec</quote>, the queries are
|
||||
variable to the value <literal>noexec</literal>, the queries are
|
||||
just shown but are not actually sent to the backend and
|
||||
executed.
|
||||
</para>
|
||||
@ -1817,7 +1845,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>ENCODING</envar></term>
|
||||
<term><varname>ENCODING</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The current client multibyte encoding. If you are not set up to
|
||||
@ -1828,7 +1856,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>HISTCONTROL</envar></term>
|
||||
<term><varname>HISTCONTROL</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If this variable is set to <literal>ignorespace</literal>,
|
||||
@ -1849,7 +1877,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>HISTSIZE</envar></term>
|
||||
<term><varname>HISTSIZE</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The number of commands to store in the command history. The
|
||||
@ -1865,7 +1893,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>HOST</envar></term>
|
||||
<term><varname>HOST</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The database server host you are currently connected to. This is
|
||||
@ -1876,15 +1904,16 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>IGNOREEOF</envar></term>
|
||||
<term><varname>IGNOREEOF</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If unset, sending an EOF character (usually Control-D) to an
|
||||
interactive session of <application>psql</application> will
|
||||
terminate the application. If set to a numeric value, that many
|
||||
EOF characters are ignored before the application terminates.
|
||||
If the variable is set but has no numeric value, the default is
|
||||
10.
|
||||
If unset, sending an <acronym>EOF</> character (usually
|
||||
<keycombo action="simul"><keycap>Control</><keycap>D</></>)
|
||||
to an interactive session of <application>psql</application>
|
||||
will terminate the application. If set to a numeric value,
|
||||
that many <acronym>EOF</> characters are ignored before the
|
||||
application terminates. If the variable is set but has no
|
||||
numeric value, the default is 10.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
@ -1896,10 +1925,10 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>LASTOID</envar></term>
|
||||
<term><varname>LASTOID</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The value of the last affected oid, as returned from an
|
||||
The value of the last affected OID, as returned from an
|
||||
<command>INSERT</command> or <command>lo_insert</command>
|
||||
command. This variable is only guaranteed to be valid until
|
||||
after the result of the next <acronym>SQL</acronym> command has
|
||||
@ -1909,7 +1938,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>LO_TRANSACTION</envar></term>
|
||||
<term><varname>LO_TRANSACTION</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If you use the <productname>PostgreSQL</productname> large
|
||||
@ -1943,7 +1972,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>ON_ERROR_STOP</envar></term>
|
||||
<term><varname>ON_ERROR_STOP</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
By default, if non-interactive scripts encounter an error, such
|
||||
@ -1963,7 +1992,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PORT</envar></term>
|
||||
<term><varname>PORT</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The database server port to which you are currently connected.
|
||||
@ -1974,7 +2003,9 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>PROMPT1</envar>, <envar>PROMPT2</envar>, <envar>PROMPT3</envar></term>
|
||||
<term><varname>PROMPT1</varname></term>
|
||||
<term><varname>PROMPT2</varname></term>
|
||||
<term><varname>PROMPT3</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
These specify what the prompt <application>psql</application>
|
||||
@ -1986,7 +2017,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>QUIET</envar></term>
|
||||
<term><varname>QUIET</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This variable is equivalent to the command line option
|
||||
@ -1997,7 +2028,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>SINGLELINE</envar></term>
|
||||
<term><varname>SINGLELINE</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This variable is set by the command line option
|
||||
@ -2007,7 +2038,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>SINGLESTEP</envar></term>
|
||||
<term><varname>SINGLESTEP</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This variable is equivalent to the command line option
|
||||
@ -2017,7 +2048,7 @@ bar
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><envar>USER</envar></term>
|
||||
<term><varname>USER</varname></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The database user you are currently connected as. This is set
|
||||
@ -2105,8 +2136,8 @@ testdb=> <userinput>\set content '\'' `sed -e "s/'/\\\\\\'/g" < my_file.txt` '\'
|
||||
|
||||
<para>
|
||||
The prompts <application>psql</application> issues can be customized
|
||||
to your preference. The three variables <envar>PROMPT1</envar>,
|
||||
<envar>PROMPT2</envar>, and <envar>PROMPT3</envar> contain strings
|
||||
to your preference. The three variables <varname>PROMPT1</varname>,
|
||||
<varname>PROMPT2</varname>, and <varname>PROMPT3</varname> contain strings
|
||||
and special escape sequences that describe the appearance of the
|
||||
prompt. Prompt 1 is the normal prompt that is issued when
|
||||
<application>psql</application> requests a new query. Prompt 2 is
|
||||
@ -2251,11 +2282,11 @@ testdb=> <userinput>\set content '\'' `sed -e "s/'/\\\\\\'/g" < my_file.txt` '\'
|
||||
</refsect3>
|
||||
|
||||
<refsect3>
|
||||
<title>Readline</title>
|
||||
<title>Command-Line Editing</title>
|
||||
|
||||
<para>
|
||||
<application>psql</application> supports the readline and history
|
||||
libraries for convenient line editing and retrieval. The command
|
||||
<application>psql</application> supports the <application>Readline</application>
|
||||
library for convenient line editing and retrieval. The command
|
||||
history is stored in a file named <filename>.psql_history</filename>
|
||||
in your home directory and is reloaded when
|
||||
<application>psql</application> starts up. Tab-completion is also
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v 1.12 2002/06/23 03:45:15 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reindex.sgml,v 1.13 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -193,14 +193,15 @@ REINDEX
|
||||
as there is in <application>psql</>. To continue a command
|
||||
across multiple lines, you must type backslash just before each
|
||||
newline except the last one.
|
||||
Also, you won't have any of the conveniences of readline processing
|
||||
Also, you won't have any of the conveniences of command-line editing
|
||||
(no command history, for example).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
To quit the backend, type EOF (control-D, usually).
|
||||
To quit the backend, type <acronym>EOF</> (<keycombo
|
||||
action="simul"><keycap>Control</><keycap>D</></>, usually).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reset.sgml,v 1.14 2002/05/17 01:19:16 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/reset.sgml,v 1.15 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -79,7 +79,7 @@ SET <replaceable class="parameter">variable</replaceable> TO DEFAULT
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
<para>
|
||||
Set DateStyle to its default value:
|
||||
Set <varname>DateStyle</> to its default value:
|
||||
|
||||
<screen>
|
||||
RESET DateStyle;
|
||||
@ -87,7 +87,7 @@ RESET DateStyle;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Set Geqo to its default value:
|
||||
Set <varname>geqo</> to its default value:
|
||||
|
||||
<screen>
|
||||
RESET GEQO;
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.60 2002/08/30 16:00:41 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.61 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -451,8 +451,8 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
|
||||
(i.e., all combined rows that pass its ON condition), plus one copy of each
|
||||
row in the left-hand table for which there was no right-hand row that
|
||||
passed the ON condition. This left-hand row is extended to the full
|
||||
width of the joined table by inserting NULLs for the right-hand columns.
|
||||
Note that only the JOIN's own ON or USING condition is considered while
|
||||
width of the joined table by inserting null values for the right-hand columns.
|
||||
Note that only the <literal>JOIN</>'s own ON or USING condition is considered while
|
||||
deciding which rows have matches. Outer ON or WHERE conditions are
|
||||
applied afterwards.
|
||||
</para>
|
||||
@ -647,11 +647,13 @@ SELECT name FROM distributors ORDER BY code;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Optionally one may add the keyword DESC (descending)
|
||||
or ASC (ascending) after each column name in the ORDER BY clause.
|
||||
If not specified, ASC is assumed by default. Alternatively, a
|
||||
specific ordering operator name may be specified. ASC is equivalent
|
||||
to USING < and DESC is equivalent to USING >.
|
||||
Optionally one may add the key word <literal>DESC</> (descending)
|
||||
or <literal>ASC</> (ascending) after each column name in the
|
||||
<literal>ORDER BY</> clause. If not specified, <literal>ASC</> is
|
||||
assumed by default. Alternatively, a specific ordering operator
|
||||
name may be specified. <literal>ASC</> is equivalent to
|
||||
<literal>USING <</> and <literal>DESC</> is equivalent to
|
||||
<literal>USING ></>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -689,7 +691,7 @@ SELECT name FROM distributors ORDER BY code;
|
||||
<para>
|
||||
The UNION operator computes the collection (set union) of the rows
|
||||
returned by the queries involved.
|
||||
The two SELECTs that represent the direct operands of the UNION must
|
||||
The two SELECT statements that represent the direct operands of the UNION must
|
||||
produce the same number of columns, and corresponding columns must be
|
||||
of compatible data types.
|
||||
</para>
|
||||
@ -1064,7 +1066,7 @@ SELECT * FROM distributors_2(111) AS (f1 int, f2 text);
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> allows one to omit
|
||||
the <command>FROM</command> clause from a query. This feature
|
||||
was retained from the original PostQuel query language. It has
|
||||
was retained from the original PostQUEL query language. It has
|
||||
a straightforward use to compute the results of simple expressions:
|
||||
|
||||
<programlisting>
|
||||
@ -1075,7 +1077,7 @@ SELECT 2+2;
|
||||
4
|
||||
</programlisting>
|
||||
|
||||
Some other DBMSes cannot do this except by introducing a dummy one-row
|
||||
Some other SQL databases cannot do this except by introducing a dummy one-row
|
||||
table to do the select from. A less obvious use is to abbreviate a
|
||||
normal select from one or more tables:
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v 1.64 2002/08/04 05:09:36 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v 1.65 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -113,7 +113,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>DATESTYLE</term>
|
||||
<term><varname>DATESTYLE</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Choose the date/time representation style. Two separate
|
||||
@ -126,7 +126,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>ISO</term>
|
||||
<term><literal>ISO</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use ISO 8601-style dates and times (<literal>YYYY-MM-DD
|
||||
@ -136,7 +136,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>SQL</term>
|
||||
<term><literal>SQL</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use Oracle/Ingres-style dates and times. Note that this
|
||||
@ -147,7 +147,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>PostgreSQL</term>
|
||||
<term><literal>PostgreSQL</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use traditional <productname>PostgreSQL</productname> format.
|
||||
@ -156,7 +156,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>German</term>
|
||||
<term><literal>German</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <literal>dd.mm.yyyy</literal> for numeric date representations.
|
||||
@ -173,7 +173,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>European</term>
|
||||
<term><literal>European</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <literal>dd/mm/yyyy</literal> for numeric date representations.
|
||||
@ -182,8 +182,8 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>NonEuropean</term>
|
||||
<term>US</term>
|
||||
<term><literal>NonEuropean</></term>
|
||||
<term><literal>US</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <literal>mm/dd/yyyy</literal> for numeric date representations.
|
||||
@ -209,7 +209,7 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are several now-deprecated means for setting the datestyle
|
||||
There are several now-deprecated means for setting the date style
|
||||
in addition to the normal methods of setting it via <command>SET</> or
|
||||
a configuration-file entry:
|
||||
<simplelist>
|
||||
@ -225,9 +225,9 @@ SET [ SESSION | LOCAL ] TIME ZONE { <replaceable class="PARAMETER">timezone</rep
|
||||
</member>
|
||||
<member>
|
||||
Setting the client's <envar>PGDATESTYLE</envar> environment variable.
|
||||
If PGDATESTYLE is set in the frontend environment of a client
|
||||
based on libpq, libpq will automatically set DATESTYLE to the
|
||||
value of PGDATESTYLE during connection start-up. This is
|
||||
If <envar>PGDATESTYLE</envar> is set in the frontend environment of a client
|
||||
based on <application>libpq</>, <application>libpq</> will automatically set <varname>DATESTYLE</> to the
|
||||
value of <envar>PGDATESTYLE</envar> during connection start-up. This is
|
||||
equivalent to a manually issued <command>SET DATESTYLE</>.
|
||||
</member>
|
||||
</simplelist>
|
||||
@ -283,7 +283,7 @@ SELECT setseed(<replaceable>value</replaceable>);
|
||||
<para>
|
||||
Shows the server-side multibyte encoding. (At present, this
|
||||
parameter can be shown but not set, because the encoding is
|
||||
determined at initdb time.)
|
||||
determined at <application>initdb</> time.)
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -373,7 +373,7 @@ SELECT setseed(<replaceable>value</replaceable>);
|
||||
|
||||
<para>
|
||||
If the <envar>PGTZ</envar> environment variable is set in the frontend
|
||||
environment of a client based on libpq, libpq will automatically
|
||||
environment of a client based on <application>libpq</>, <application>libpq</> will automatically
|
||||
<command>SET TIMEZONE</command> to the value of
|
||||
<envar>PGTZ</envar> during connection start-up.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.6 2002/05/17 01:19:16 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/set_session_auth.sgml,v 1.7 2002/09/21 18:32:54 petere Exp $ -->
|
||||
<refentry id="SQL-SET-SESSION-AUTHORIZATION">
|
||||
<docinfo>
|
||||
<date>2001-04-21</date>
|
||||
@ -48,7 +48,7 @@ RESET SESSION AUTHORIZATION
|
||||
The session user identifier may be changed only if the initial session
|
||||
user (the <firstterm>authenticated user</firstterm>) had the
|
||||
superuser privilege. Otherwise, the command is accepted only if it
|
||||
specifies the authenticated username.
|
||||
specifies the authenticated user name.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.19 2002/08/13 20:40:44 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.20 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -90,7 +90,7 @@ UNLISTEN { <replaceable class="PARAMETER">notifyname</replaceable> | * }
|
||||
<para>
|
||||
<command>UNLISTEN</command>
|
||||
is used to remove an existing <command>NOTIFY</command> registration.
|
||||
UNLISTEN cancels any existing registration of the current
|
||||
<command>UNLISTEN</command> cancels any existing registration of the current
|
||||
<productname>PostgreSQL</productname> session as a listener on the notify
|
||||
condition <replaceable class="PARAMETER">notifyname</replaceable>.
|
||||
The special condition wildcard <literal>*</literal> cancels all listener registrations
|
||||
@ -117,7 +117,7 @@ UNLISTEN { <replaceable class="PARAMETER">notifyname</replaceable> | * }
|
||||
as a name up to 64 characters long.
|
||||
</para>
|
||||
<para>
|
||||
The backend does not complain if you UNLISTEN something you were not
|
||||
The backend does not complain if you unlisten something you were not
|
||||
listening for.
|
||||
Each backend will automatically execute <command>UNLISTEN *</command> when
|
||||
exiting.
|
||||
@ -143,7 +143,7 @@ Asynchronous NOTIFY 'virtual' from backend with pid '8448' received
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once UNLISTEN has been executed, further NOTIFY commands will be
|
||||
Once <command>UNLISTEN</> has been executed, further <command>NOTIFY</> commands will be
|
||||
ignored:
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.25 2002/04/23 02:07:16 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.26 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -162,7 +162,7 @@ INFO: Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
|
||||
<para>
|
||||
<command>VACUUM</command> reclaims storage occupied by deleted tuples.
|
||||
In normal <productname>PostgreSQL</productname> operation, tuples that
|
||||
are DELETEd or obsoleted by UPDATE are not physically removed from
|
||||
are deleted or obsoleted by UPDATE are not physically removed from
|
||||
their table; they remain present until a <command>VACUUM</command> is
|
||||
done. Therefore it's necessary to do <command>VACUUM</command>
|
||||
periodically, especially on frequently-updated tables.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuumdb.sgml,v 1.25 2002/09/05 22:05:50 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuumdb.sgml,v 1.26 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -79,8 +79,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-d <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term>--dbname <replaceable class="parameter">dbname</replaceable></term>
|
||||
<term><option>-d <replaceable class="parameter">dbname</replaceable></option></term>
|
||||
<term><option>--dbname <replaceable class="parameter">dbname</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the name of the database to be cleaned or analyzed.
|
||||
@ -94,8 +94,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-a</term>
|
||||
<term>--all</term>
|
||||
<term><option>-a</option></term>
|
||||
<term><option>--all</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Vacuum all databases.
|
||||
@ -104,8 +104,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-f</term>
|
||||
<term>--full</term>
|
||||
<term><option>-f</option></term>
|
||||
<term><option>--full</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Perform <quote>full</quote> vacuuming.
|
||||
@ -114,8 +114,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-v</term>
|
||||
<term>--verbose</term>
|
||||
<term><option>-v</option></term>
|
||||
<term><option>--verbose</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Print detailed information during processing.
|
||||
@ -124,8 +124,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-z</term>
|
||||
<term>--analyze</term>
|
||||
<term><option>-z</option></term>
|
||||
<term><option>--analyze</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Calculate statistics for use by the optimizer.
|
||||
@ -134,8 +134,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-t <replaceable class="parameter">table</replaceable> [ (<replaceable class="parameter">column</replaceable> [,...]) ]</term>
|
||||
<term>--table <replaceable class="parameter">table</replaceable> [ (<replaceable class="parameter">column</replaceable> [,...]) ]</term>
|
||||
<term><option>-t <replaceable class="parameter">table</replaceable> [ (<replaceable class="parameter">column</replaceable> [,...]) ]</option></term>
|
||||
<term><option>--table <replaceable class="parameter">table</replaceable> [ (<replaceable class="parameter">column</replaceable> [,...]) ]</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Clean or analyze <replaceable class="parameter">table</replaceable> only.
|
||||
@ -160,8 +160,8 @@ PostgreSQL documentation
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>-h <replaceable class="parameter">host</replaceable></term>
|
||||
<term>--host <replaceable class="parameter">host</replaceable></term>
|
||||
<term><option>-h <replaceable class="parameter">host</replaceable></></term>
|
||||
<term><option>--host <replaceable class="parameter">host</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the host name of the machine on which the
|
||||
@ -173,8 +173,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-p <replaceable class="parameter">port</replaceable></term>
|
||||
<term>--port <replaceable class="parameter">port</replaceable></term>
|
||||
<term><option>-p <replaceable class="parameter">port</replaceable></></term>
|
||||
<term><option>--port <replaceable class="parameter">port</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the Internet TCP/IP port or local Unix domain socket file
|
||||
@ -185,8 +185,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-U <replaceable class="parameter">username</replaceable></term>
|
||||
<term>--username <replaceable class="parameter">username</replaceable></term>
|
||||
<term><option>-U <replaceable class="parameter">username</replaceable></></term>
|
||||
<term><option>--username <replaceable class="parameter">username</replaceable></></term>
|
||||
<listitem>
|
||||
<para>
|
||||
User name to connect as
|
||||
@ -195,8 +195,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-W</term>
|
||||
<term>--password</term>
|
||||
<term><option>-W</></term>
|
||||
<term><option>--password</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Force password prompt.
|
||||
@ -205,8 +205,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-e</term>
|
||||
<term>--echo</term>
|
||||
<term><option>-e</></term>
|
||||
<term><option>--echo</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Echo the commands that <application>vacuumdb</application> generates
|
||||
@ -216,8 +216,8 @@ PostgreSQL documentation
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>-q</term>
|
||||
<term>--quiet</term>
|
||||
<term><option>-q</></term>
|
||||
<term><option>--quiet</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Do not display a response.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.27 2002/05/14 13:05:42 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.28 2002/09/21 18:32:53 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
@ -87,8 +87,8 @@
|
||||
<para>
|
||||
The parallel regression test starts quite a few processes under your
|
||||
user ID. Presently, the maximum concurrency is twenty parallel test
|
||||
scripts, which means sixty processes --- there's a backend, a psql,
|
||||
and usually a shell parent process for the psql for each test script.
|
||||
scripts, which means sixty processes --- there's a backend, a <application>psql</>,
|
||||
and usually a shell parent process for the <application>psql</> for each test script.
|
||||
So if your system enforces a per-user limit on the number of processes,
|
||||
make sure this limit is at least seventy-five or so, else you may get
|
||||
random-seeming failures in the parallel test. If you are not in
|
||||
@ -184,7 +184,7 @@
|
||||
problem by providing alternative result files that together are
|
||||
known to handle a large number of locales. For example, for the
|
||||
<quote>char</quote> test, the expected file
|
||||
<filename>char.out</filename> handles the C and POSIX locales,
|
||||
<filename>char.out</filename> handles the <literal>C</> and <literal>POSIX</> locales,
|
||||
and the file <filename>char_1.out</filename> handles many other
|
||||
locales. The regression test driver will automatically pick the
|
||||
best file to match against when checking for success and for
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.159 2002/09/18 21:35:20 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.160 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="release">
|
||||
@ -598,7 +598,7 @@ Reject invalid multibyte character sequences (Tatsuo)
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>PL/pgSQL</title>
|
||||
<title><application>PL/pgSQL</></title>
|
||||
<literallayout>
|
||||
Now uses portals for SELECT loops, allowing huge result sets (Jan)
|
||||
CURSOR and REFCURSOR support (Jan)
|
||||
@ -638,7 +638,7 @@ Add spi_lastoid function (bob@redivi.com)
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Psql</title>
|
||||
<title><application>Psql</></title>
|
||||
<literallayout>
|
||||
\d displays indexes in unique, primary groupings (Christopher Kings-Lynne)
|
||||
Allow trailing semicolons in backslash commands (Greg Sabino Mullane)
|
||||
@ -649,7 +649,7 @@ Format the correct number of columns for Unicode (Patrice)
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Libpq</title>
|
||||
<title><application>Libpq</></title>
|
||||
<literallayout>
|
||||
New function PQescapeString() to escape quotes in command strings (Florian Weimer)
|
||||
New function PQescapeBytea() escapes binary strings for use as SQL string literals
|
||||
@ -711,7 +711,7 @@ Add more compatibility functions to odbc.sql (Peter E)
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>ECPG</title>
|
||||
<title><application>ECPG</></title>
|
||||
<literallayout>
|
||||
EXECUTE ... INTO implemented (Christof Petig)
|
||||
Multiple row descriptor support (e.g. CARDINALITY) (Christof Petig)
|
||||
@ -981,7 +981,7 @@ outer join syntax.
|
||||
<listitem>
|
||||
<para>
|
||||
The previous C function manager did not
|
||||
handle NULLs properly, nor did it support 64-bit <acronym>CPU</acronym>'s (Alpha). The new
|
||||
handle null values properly, nor did it support 64-bit <acronym>CPU</acronym>'s (Alpha). The new
|
||||
function manager does. You can continue using your old custom
|
||||
functions, but you may want to rewrite them in the future to use the new
|
||||
function manager call interface.
|
||||
@ -1438,9 +1438,11 @@ ecpg changes (Michael)
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
SQL92 join syntax is now supported, though only as INNER JOINs
|
||||
for this release. JOIN, NATURAL JOIN, JOIN/USING, JOIN/ON are
|
||||
available, as are column correlation names.
|
||||
SQL92 join syntax is now supported, though only as
|
||||
<literal>INNER JOIN</> for this release. <literal>JOIN</>,
|
||||
<literal>NATURAL JOIN</>, <literal>JOIN</>/<literal>USING</>,
|
||||
and <literal>JOIN</>/<literal>ON</> are available, as are
|
||||
column correlation names.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2530,7 +2532,7 @@ original <application>PL/pgTCL</application> procedural language he contributed
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
We have optional multiple-byte character set support from Tatsuo Iishi
|
||||
We have optional multiple-byte character set support from Tatsuo Ishii
|
||||
to complement our existing locale support.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3592,10 +3594,11 @@ optimizer which uses <firstterm>genetic</firstterm>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The "random" results in the random test should cause the "random" test
|
||||
to be "failed", since the regression tests are evaluated using a simple
|
||||
diff. However, "random" does not seem to produce random results on my
|
||||
test machine (Linux/gcc/i686).
|
||||
The <quote>random</> results in the random test should cause the
|
||||
<quote>random</quote> test to be <quote>failed</quote>, since the
|
||||
regression tests are evaluated using a simple diff. However,
|
||||
<quote>random</> does not seem to produce random results on my test
|
||||
machine (Linux/<application>gcc</>/i686).
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
@ -3946,7 +3949,7 @@ than NULL. See the copy manual page for full details.
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
If you are loading an older binary copy or non-stdout copy, there is no
|
||||
If you are loading an older binary copy or non-<systemitem>stdout</> copy, there is no
|
||||
end-of-data character, and hence no conversion necessary.
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.23 2002/04/19 23:13:53 tgl Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.24 2002/09/21 18:32:53 petere Exp $ -->
|
||||
|
||||
<Chapter Id="rules">
|
||||
<Title>The Rule System</Title>
|
||||
@ -179,7 +179,7 @@
|
||||
|
||||
<Para>
|
||||
DELETE queries don't need a target list because they don't
|
||||
produce any result. In fact the planner will add a special CTID
|
||||
produce any result. In fact the planner will add a special <acronym>CTID</>
|
||||
entry to the empty target list. But this is after the rule
|
||||
system and will be discussed later. For the rule system the
|
||||
target list is empty.
|
||||
@ -199,7 +199,7 @@
|
||||
expressions from the SET attribute = expression part of the query.
|
||||
The planner will add missing columns by inserting expressions that
|
||||
copy the values from the old row into the new one. And it will add
|
||||
the special CTID entry just as for DELETE too.
|
||||
the special <acronym>CTID</> entry just as for DELETE too.
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
@ -781,24 +781,25 @@ SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
|
||||
|
||||
<Para>
|
||||
To resolve this problem, another entry is added to the target list
|
||||
in UPDATE (and also in DELETE) statements: the current tuple ID (CTID).
|
||||
in UPDATE (and also in DELETE) statements: the current tuple ID (<acronym>CTID</>).
|
||||
This is a system attribute containing the file
|
||||
block number and position in the block for the row. Knowing the table,
|
||||
the CTID can be used to retrieve the original t1 row to be updated.
|
||||
After adding the CTID to the target list, the query actually looks like
|
||||
the <acronym>CTID</> can be used to retrieve the original t1 row to be updated.
|
||||
After adding the <acronym>CTID</> to the target list, the query actually looks like
|
||||
|
||||
<ProgramListing>
|
||||
SELECT t1.a, t2.b, t1.ctid FROM t1, t2 WHERE t1.a = t2.a;
|
||||
</ProgramListing>
|
||||
|
||||
Now another detail of <ProductName>PostgreSQL</ProductName> enters the
|
||||
stage. At this moment, table rows aren't overwritten and this is why
|
||||
ABORT TRANSACTION is fast. In an UPDATE, the new result row is inserted
|
||||
into the table (after stripping CTID) and in the tuple header of the row
|
||||
that CTID pointed to the cmax and xmax entries are set to the current
|
||||
command counter and current transaction ID. Thus the old row is hidden
|
||||
and after the transaction committed the vacuum cleaner can really move
|
||||
it out.
|
||||
Now another detail of <ProductName>PostgreSQL</ProductName> enters
|
||||
the stage. At this moment, table rows aren't overwritten and this
|
||||
is why ABORT TRANSACTION is fast. In an UPDATE, the new result row
|
||||
is inserted into the table (after stripping <acronym>CTID</>) and
|
||||
in the tuple header of the row that <acronym>CTID</> pointed to
|
||||
the <literal>cmax</> and <literal>xmax</> entries are set to the
|
||||
current command counter and current transaction ID. Thus the old
|
||||
row is hidden and after the transaction committed the vacuum
|
||||
cleaner can really move it out.
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.137 2002/09/18 20:09:32 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.138 2002/09/21 18:32:53 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
@ -528,7 +528,7 @@ postmaster -c log_connections=yes -c syslog=2
|
||||
<programlisting>
|
||||
env PGOPTIONS='-c geqo=off' psql
|
||||
</programlisting>
|
||||
(This works for any libpq-based client application, not just
|
||||
(This works for any <application>libpq</>-based client application, not just
|
||||
<application>psql</application>.) Note that this won't work for
|
||||
options that are fixed when the server is started, such as the port
|
||||
number.
|
||||
@ -1002,7 +1002,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<listitem>
|
||||
<para>
|
||||
Determines whether <command>EXPLAIN VERBOSE</> uses the indented
|
||||
or non-indented format for displaying detailed querytree dumps.
|
||||
or non-indented format for displaying detailed query-tree dumps.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1058,10 +1058,10 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<term><varname>LOG_PID</varname> (<type>boolean</type>)</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Prefixes each server message in the logfile with the process ID of
|
||||
Prefixes each server message in the log file with the process ID of
|
||||
the backend process. This is useful to sort out which messages
|
||||
pertain to which connection. The default is off. This parameter
|
||||
does not affect messages logged via syslog(), which always contain
|
||||
does not affect messages logged via <application>syslog</>, which always contain
|
||||
the process ID.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1669,7 +1669,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
<listitem>
|
||||
<para>
|
||||
This variable specifies the order in which namespaces are searched
|
||||
when an object (table, datatype, function, etc) is referenced by a
|
||||
when an object (table, data type, function, etc) is referenced by a
|
||||
simple name with no schema component. When there are objects of
|
||||
identical names in different namespaces, the one found first
|
||||
in the search path is used. An object that is not in any of the
|
||||
@ -1865,7 +1865,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
However, filtered forms in <productname>Microsoft
|
||||
Access</productname> generate queries that appear to use
|
||||
<literal><replaceable>expr</> = NULL</literal> to test for
|
||||
NULLs, so if you use that interface to access the database you
|
||||
null values, so if you use that interface to access the database you
|
||||
might want to turn this option on. Since expressions of the
|
||||
form <literal><replaceable>expr</> = NULL</literal> always
|
||||
return NULL (using the correct interpretation) they are not
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.69 2002/09/12 22:05:36 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.70 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -715,19 +715,19 @@ SELECT (5 !) - 6;
|
||||
<row>
|
||||
<entry><token>IS</token></entry>
|
||||
<entry></entry>
|
||||
<entry>test for TRUE, FALSE, UNKNOWN, NULL</entry>
|
||||
<entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS UNKNOWN</>, <literal>IS NULL</></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><token>ISNULL</token></entry>
|
||||
<entry></entry>
|
||||
<entry>test for NULL</entry>
|
||||
<entry>test for null</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><token>NOTNULL</token></entry>
|
||||
<entry></entry>
|
||||
<entry>test for NOT NULL</entry>
|
||||
<entry>test for not null</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -1042,13 +1042,13 @@ sqrt(2)
|
||||
<para>
|
||||
The first form of aggregate expression invokes the aggregate
|
||||
across all input rows for which the given expression yields a
|
||||
non-NULL value. (Actually, it is up to the aggregate function
|
||||
whether to ignore NULLs or not --- but all the standard ones do.)
|
||||
non-null value. (Actually, it is up to the aggregate function
|
||||
whether to ignore null values or not --- but all the standard ones do.)
|
||||
The second form is the same as the first, since
|
||||
<literal>ALL</literal> is the default. The third form invokes the
|
||||
aggregate for all distinct non-NULL values of the expression found
|
||||
aggregate for all distinct non-null values of the expression found
|
||||
in the input rows. The last form invokes the aggregate once for
|
||||
each input row regardless of NULL or non-NULL values; since no
|
||||
each input row regardless of null or non-null values; since no
|
||||
particular input value is specified, it is generally only useful
|
||||
for the <function>count()</function> aggregate function.
|
||||
</para>
|
||||
@ -1056,9 +1056,9 @@ sqrt(2)
|
||||
<para>
|
||||
For example, <literal>count(*)</literal> yields the total number
|
||||
of input rows; <literal>count(f1)</literal> yields the number of
|
||||
input rows in which <literal>f1</literal> is non-NULL;
|
||||
input rows in which <literal>f1</literal> is non-null;
|
||||
<literal>count(distinct f1)</literal> yields the number of
|
||||
distinct non-NULL values of <literal>f1</literal>.
|
||||
distinct non-null values of <literal>f1</literal>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1106,7 +1106,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
||||
to the type that a value expression must produce (for example, when it is
|
||||
assigned to a table column); the system will automatically apply a
|
||||
type cast in such cases. However, automatic casting is only done for
|
||||
cast functions that are marked <quote>okay to apply implicitly</>
|
||||
cast functions that are marked <quote>OK to apply implicitly</>
|
||||
in the system catalogs. Other cast functions must be invoked with
|
||||
explicit casting syntax. This restriction is intended to prevent
|
||||
surprising conversions from being applied silently.
|
||||
@ -1140,7 +1140,7 @@ CAST ( <replaceable>expression</replaceable> AS <replaceable>type</replaceable>
|
||||
It is an error to use a query that
|
||||
returns more than one row or more than one column as a scalar subquery.
|
||||
(But if, during a particular execution, the subquery returns no rows,
|
||||
there is no error; the scalar result is taken to be NULL.)
|
||||
there is no error; the scalar result is taken to be null.)
|
||||
The subquery can refer to variables from the surrounding query,
|
||||
which will act as constants during any one evaluation of the subquery.
|
||||
See also <xref linkend="functions-subquery">.
|
||||
|
@ -1,17 +1,18 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.24 2002/08/22 00:01:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.25 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="triggers">
|
||||
<title>Triggers</title>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> has various server-side function
|
||||
interfaces. Server-side functions can be written in SQL, PL/pgSQL,
|
||||
Tcl, or C. Trigger functions can be written in any of these
|
||||
languages except SQL. Note that statement-level trigger events are not
|
||||
supported in the current version. You can currently specify BEFORE or
|
||||
AFTER on INSERT, DELETE or UPDATE of a tuple as a trigger event.
|
||||
<productname>PostgreSQL</productname> has various server-side
|
||||
function interfaces. Server-side functions can be written in SQL,
|
||||
C, or any defined procedural language. Trigger functions can be
|
||||
written in C and most procedural languages, but not in SQL. Note that
|
||||
statement-level trigger events are not supported in the current
|
||||
version. You can currently specify BEFORE or AFTER on INSERT,
|
||||
DELETE or UPDATE of a tuple as a trigger event.
|
||||
</para>
|
||||
|
||||
<sect1 id="trigger-definition">
|
||||
@ -19,7 +20,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.24 2002/08/22 00:01:40 tgl
|
||||
|
||||
<para>
|
||||
If a trigger event occurs, the trigger manager (called by the Executor)
|
||||
sets up a TriggerData information structure (described below) and calls
|
||||
sets up a <structname>TriggerData</> information structure (described below) and calls
|
||||
the trigger function to handle the event.
|
||||
</para>
|
||||
|
||||
@ -27,7 +28,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.24 2002/08/22 00:01:40 tgl
|
||||
The trigger function must be defined before the trigger itself can be
|
||||
created. The trigger function must be declared as a
|
||||
function taking no arguments and returning type <literal>trigger</>.
|
||||
(The trigger function receives its input through a TriggerData
|
||||
(The trigger function receives its input through a <structname>TriggerData</>
|
||||
structure, not in the form of ordinary function arguments.)
|
||||
If the function is written in C, it must use the <quote>version 1</>
|
||||
function manager interface.
|
||||
@ -36,12 +37,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/trigger.sgml,v 1.24 2002/08/22 00:01:40 tgl
|
||||
<para>
|
||||
The syntax for creating triggers is:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT | DELETE | UPDATE [ OR ... ] ]
|
||||
ON <replaceable>relation</replaceable> FOR EACH [ ROW | STATEMENT ]
|
||||
EXECUTE PROCEDURE <replaceable>procedure</replaceable>
|
||||
(<replaceable>args</replaceable>);
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
where the arguments are:
|
||||
|
||||
@ -116,7 +117,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<term><replaceable>args</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The arguments passed to the function in the TriggerData structure.
|
||||
The arguments passed to the function in the <structname>TriggerData</> structure.
|
||||
This is either empty or a list of one or more simple literal
|
||||
constants (which will be passed to the function as strings).
|
||||
</para>
|
||||
@ -127,7 +128,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
triggers with similar requirements to call the same function.
|
||||
As an example, there could be a generalized trigger
|
||||
function that takes as its arguments two field names and puts the
|
||||
current user in one and the current timestamp in the other.
|
||||
current user in one and the current time stamp in the other.
|
||||
Properly written, this trigger function would be independent of
|
||||
the specific table it is triggering on. So the same function
|
||||
could be used for INSERT events on any table with suitable fields,
|
||||
@ -141,15 +142,16 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Trigger functions return a HeapTuple to the calling Executor. The return
|
||||
Trigger functions return a <structname>HeapTuple</> to the calling executor. The return
|
||||
value is ignored for triggers fired AFTER an operation,
|
||||
but it allows BEFORE triggers to:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Return NULL to skip the operation for the current tuple (and so the
|
||||
tuple will not be inserted/updated/deleted).
|
||||
Return a <symbol>NULL</> pointer to skip the operation for the
|
||||
current tuple (and so the tuple will not be
|
||||
inserted/updated/deleted).
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -173,12 +175,12 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If more than one trigger
|
||||
is defined for the same event on the same relation, the triggers will
|
||||
be fired in alphabetical order by name. In the case of BEFORE triggers,
|
||||
the possibly-modified tuple returned by each trigger becomes the input
|
||||
to the next trigger. If any BEFORE trigger returns NULL, the operation
|
||||
is abandoned and subsequent triggers are not fired.
|
||||
If more than one trigger is defined for the same event on the same
|
||||
relation, the triggers will be fired in alphabetical order by
|
||||
name. In the case of BEFORE triggers, the possibly-modified tuple
|
||||
returned by each trigger becomes the input to the next trigger.
|
||||
If any BEFORE trigger returns <symbol>NULL</>, the operation is
|
||||
abandoned and subsequent triggers are not fired.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -207,24 +209,24 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
||||
<para>
|
||||
The interface described here applies for
|
||||
<productname>PostgreSQL</productname> 7.1 and later.
|
||||
Earlier versions passed the TriggerData pointer in a global
|
||||
variable CurrentTriggerData.
|
||||
Earlier versions passed the <structname>TriggerData</> pointer in a global
|
||||
variable <varname>CurrentTriggerData</>.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
<para>
|
||||
When a function is called by the trigger manager, it is not passed any
|
||||
normal parameters, but it is passed a <quote>context</> pointer pointing to a
|
||||
TriggerData structure. C functions can check whether they were called
|
||||
<structname>TriggerData</> structure. C functions can check whether they were called
|
||||
from the trigger manager or not by executing the macro
|
||||
<literal>CALLED_AS_TRIGGER(fcinfo)</literal>, which expands to
|
||||
<programlisting>
|
||||
((fcinfo)->context != NULL && IsA((fcinfo)->context, TriggerData))
|
||||
</programlisting>
|
||||
If this returns TRUE, then it is safe to cast fcinfo->context to type
|
||||
<programlisting>
|
||||
((fcinfo)->context != NULL && IsA((fcinfo)->context, TriggerData))
|
||||
</programlisting>
|
||||
If this returns true, then it is safe to cast <literal>fcinfo->context</> to type
|
||||
<literal>TriggerData *</literal> and make use of the pointed-to
|
||||
TriggerData structure.
|
||||
The function must <emphasis>not</emphasis> alter the TriggerData
|
||||
<structname>TriggerData</> structure.
|
||||
The function must <emphasis>not</emphasis> alter the <structname>TriggerData</>
|
||||
structure or any of the data it points to.
|
||||
</para>
|
||||
|
||||
@ -248,7 +250,7 @@ typedef struct TriggerData
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>type</term>
|
||||
<term><structfield>type</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Always <literal>T_TriggerData</literal> if this is a trigger event.
|
||||
@ -257,7 +259,7 @@ typedef struct TriggerData
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tg_event</term>
|
||||
<term><structfield>tg_event</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
describes the event for which the function is called. You may use the
|
||||
@ -334,21 +336,24 @@ typedef struct TriggerData
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tg_relation</term>
|
||||
<term><structfield>tg_relation</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
is a pointer to structure describing the triggered relation. Look at
|
||||
src/include/utils/rel.h for details about this structure. The most
|
||||
interesting things are tg_relation->rd_att (descriptor of the relation
|
||||
tuples) and tg_relation->rd_rel->relname (relation's name. This is not
|
||||
char*, but NameData. Use SPI_getrelname(tg_relation) to get char* if
|
||||
you need a copy of name).
|
||||
is a pointer to structure describing the triggered
|
||||
relation. Look at <filename>utils/rel.h</> for details about
|
||||
this structure. The most interesting things are
|
||||
<literal>tg_relation->rd_att</> (descriptor of the relation
|
||||
tuples) and <literal>tg_relation->rd_rel->relname</>
|
||||
(relation's name. This is not <type>char*</>, but
|
||||
<type>NameData</>. Use
|
||||
<literal>SPI_getrelname(tg_relation)</> to get <type>char*</> if you
|
||||
need a copy of the name).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tg_trigtuple</term>
|
||||
<term><structfield>tg_trigtuple</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
is a pointer to the tuple for which the trigger is fired. This is the tuple
|
||||
@ -361,10 +366,10 @@ typedef struct TriggerData
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tg_newtuple</term>
|
||||
<term><structfield>tg_newtuple</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
is a pointer to the new version of tuple if UPDATE and NULL if this is
|
||||
is a pointer to the new version of tuple if UPDATE and <symbol>NULL</> if this is
|
||||
for an INSERT or a DELETE. This is what you are to return to Executor if
|
||||
UPDATE and you don't want to replace this tuple with another one or skip
|
||||
the operation.
|
||||
@ -373,12 +378,12 @@ typedef struct TriggerData
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tg_trigger</term>
|
||||
<term><structfield>tg_trigger</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
is pointer to structure Trigger defined in src/include/utils/rel.h:
|
||||
is pointer to structure <structname>Trigger</> defined in <filename>utils/rel.h</>:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
typedef struct Trigger
|
||||
{
|
||||
Oid tgoid;
|
||||
@ -394,12 +399,13 @@ typedef struct Trigger
|
||||
int16 tgattr[FUNC_MAX_ARGS];
|
||||
char **tgargs;
|
||||
} Trigger;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
where
|
||||
tgname is the trigger's name, tgnargs is number of arguments in tgargs,
|
||||
tgargs is an array of pointers to the arguments specified in the CREATE
|
||||
TRIGGER statement. Other members are for internal use only.
|
||||
where <structfield>tgname</> is the trigger's name,
|
||||
<structfield>tgnargs</> is number of arguments in
|
||||
<structfield>tgargs</>, <structfield>tgargs</> is an array of
|
||||
pointers to the arguments specified in the CREATE TRIGGER
|
||||
statement. Other members are for internal use only.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -415,9 +421,9 @@ typedef struct Trigger
|
||||
changes made by the query itself (via SQL-function, SPI-function, triggers)
|
||||
are invisible to the query scan. For example, in query
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
INSERT INTO a SELECT * FROM a;
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
tuples inserted are invisible for SELECT scan. In effect, this
|
||||
duplicates the database table within itself (subject to unique index
|
||||
@ -438,7 +444,7 @@ execution of Q) or after Q is done.
|
||||
|
||||
<para>
|
||||
This is true for triggers as well so, though a tuple being inserted
|
||||
(tg_trigtuple) is not visible to queries in a BEFORE trigger, this tuple
|
||||
(<structfield>tg_trigtuple</>) is not visible to queries in a BEFORE trigger, this tuple
|
||||
(just inserted) is visible to queries in an AFTER trigger, and to queries
|
||||
in BEFORE/AFTER triggers fired after this!
|
||||
</para>
|
||||
@ -454,12 +460,12 @@ execution of Q) or after Q is done.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is a very simple example of trigger usage. Function trigf reports
|
||||
the number of tuples in the triggered relation ttest and skips the
|
||||
operation if the query attempts to insert NULL into x (i.e - it acts as a
|
||||
NOT NULL constraint but doesn't abort the transaction).
|
||||
Here is a very simple example of trigger usage. Function <function>trigf</> reports
|
||||
the number of tuples in the triggered relation <literal>ttest</> and skips the
|
||||
operation if the query attempts to insert a null value into x (i.e - it acts as a
|
||||
not-null constraint but doesn't abort the transaction).
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
#include "executor/spi.h" /* this is what you need to work with SPI */
|
||||
#include "commands/trigger.h" /* -"- and triggers */
|
||||
|
||||
@ -488,9 +494,9 @@ trigf(PG_FUNCTION_ARGS)
|
||||
else
|
||||
rettuple = trigdata->tg_trigtuple;
|
||||
|
||||
/* check for NULLs ? */
|
||||
if (!TRIGGER_FIRED_BY_DELETE(trigdata->tg_event) &&
|
||||
TRIGGER_FIRED_BEFORE(trigdata->tg_event))
|
||||
/* check for null values */
|
||||
if (!TRIGGER_FIRED_BY_DELETE(trigdata->tg_event)
|
||||
&& TRIGGER_FIRED_BEFORE(trigdata->tg_event))
|
||||
checknull = true;
|
||||
|
||||
if (TRIGGER_FIRED_BEFORE(trigdata->tg_event))
|
||||
@ -529,20 +535,20 @@ trigf(PG_FUNCTION_ARGS)
|
||||
|
||||
return PointerGetDatum(rettuple);
|
||||
}
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now, compile and create the trigger function:
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
CREATE FUNCTION trigf () RETURNS TRIGGER AS
|
||||
'...path_to_so' LANGUAGE 'C';
|
||||
'...path_to_so' LANGUAGE C;
|
||||
|
||||
CREATE TABLE ttest (x int4);
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
vac=> CREATE TRIGGER tbefore BEFORE INSERT OR UPDATE OR DELETE ON ttest
|
||||
FOR EACH ROW EXECUTE PROCEDURE trigf();
|
||||
CREATE
|
||||
@ -556,8 +562,8 @@ INSERT 0 0
|
||||
-- Insertion skipped and AFTER trigger is not fired
|
||||
|
||||
vac=> SELECT * FROM ttest;
|
||||
x
|
||||
-
|
||||
x
|
||||
---
|
||||
(0 rows)
|
||||
|
||||
vac=> INSERT INTO ttest VALUES (1);
|
||||
@ -567,9 +573,9 @@ INFO: trigf (fired after ): there are 1 tuples in ttest
|
||||
remember what we said about visibility.
|
||||
INSERT 167793 1
|
||||
vac=> SELECT * FROM ttest;
|
||||
x
|
||||
-
|
||||
1
|
||||
x
|
||||
---
|
||||
1
|
||||
(1 row)
|
||||
|
||||
vac=> INSERT INTO ttest SELECT x * 2 FROM ttest;
|
||||
@ -579,13 +585,13 @@ INFO: trigf (fired after ): there are 2 tuples in ttest
|
||||
remember what we said about visibility.
|
||||
INSERT 167794 1
|
||||
vac=> SELECT * FROM ttest;
|
||||
x
|
||||
-
|
||||
1
|
||||
2
|
||||
x
|
||||
---
|
||||
1
|
||||
2
|
||||
(2 rows)
|
||||
|
||||
vac=> UPDATE ttest SET x = null WHERE x = 2;
|
||||
vac=> UPDATE ttest SET x = NULL WHERE x = 2;
|
||||
INFO: trigf (fired before): there are 2 tuples in ttest
|
||||
UPDATE 0
|
||||
vac=> UPDATE ttest SET x = 4 WHERE x = 2;
|
||||
@ -593,10 +599,10 @@ INFO: trigf (fired before): there are 2 tuples in ttest
|
||||
INFO: trigf (fired after ): there are 2 tuples in ttest
|
||||
UPDATE 1
|
||||
vac=> SELECT * FROM ttest;
|
||||
x
|
||||
-
|
||||
1
|
||||
4
|
||||
x
|
||||
---
|
||||
1
|
||||
4
|
||||
(2 rows)
|
||||
|
||||
vac=> DELETE FROM ttest;
|
||||
@ -608,10 +614,10 @@ INFO: trigf (fired after ): there are 0 tuples in ttest
|
||||
remember what we said about visibility.
|
||||
DELETE 2
|
||||
vac=> SELECT * FROM ttest;
|
||||
x
|
||||
-
|
||||
x
|
||||
---
|
||||
(0 rows)
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.16 2002/01/07 02:29:14 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.17 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xaggr">
|
||||
@ -86,7 +86,7 @@ SELECT complex_sum(a) FROM test_complex;
|
||||
<para>
|
||||
Another bit of default behavior for a <quote>strict</> transition function
|
||||
is that the previous state value is retained unchanged whenever a
|
||||
NULL input value is encountered. Thus, NULLs are ignored. If you
|
||||
NULL input value is encountered. Thus, null values are ignored. If you
|
||||
need some other behavior for NULL inputs, just define your transition
|
||||
function as non-strict, and code it to test for NULL inputs and do
|
||||
whatever is needed.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.60 2002/09/01 16:28:05 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.61 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
@ -1183,7 +1183,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
|
||||
meaning that
|
||||
the system should automatically assume a NULL result if any input
|
||||
value is NULL. By doing this, we avoid having to check for NULL inputs
|
||||
in the function code. Without this, we'd have to check for NULLs
|
||||
in the function code. Without this, we'd have to check for null values
|
||||
explicitly, for example by checking for a null pointer for each
|
||||
pass-by-reference argument. (For pass-by-value arguments, we don't
|
||||
even have a way to check!)
|
||||
@ -1497,7 +1497,7 @@ LANGUAGE C;
|
||||
either base (scalar) data types, or composite (multi-column) data types.
|
||||
The API is split into two main components: support for returning
|
||||
composite data types, and support for returning multiple rows
|
||||
(set returning functions or SRFs).
|
||||
(set returning functions or <acronym>SRF</>s).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1511,17 +1511,19 @@ LANGUAGE C;
|
||||
</para>
|
||||
|
||||
<sect3>
|
||||
<title>Returning Tuples (Composite Types)</title>
|
||||
<title>Returning Rows (Composite Types)</title>
|
||||
|
||||
<para>
|
||||
The Table Function API support for returning composite data types
|
||||
(or tuples) starts with the AttInMetadata struct. This struct holds
|
||||
arrays of individual attribute information needed to create a tuple from
|
||||
raw C strings. It also saves a pointer to the TupleDesc. The information
|
||||
carried here is derived from the TupleDesc, but it is stored here to
|
||||
avoid redundant CPU cycles on each call to a Table Function. In the
|
||||
case of a function returning a set, the AttInMetadata struct should be
|
||||
computed once during the first call and saved for re-use in later calls.
|
||||
(or rows) starts with the <structname>AttInMetadata</>
|
||||
structure. This structure holds arrays of individual attribute
|
||||
information needed to create a row from raw C strings. It also
|
||||
saves a pointer to the <structname>TupleDesc</>. The information
|
||||
carried here is derived from the <structname>TupleDesc</>, but it
|
||||
is stored here to avoid redundant CPU cycles on each call to a
|
||||
table function. In the case of a function returning a set, the
|
||||
<structname>AttInMetadata</> structure should be computed
|
||||
once during the first call and saved for re-use in later calls.
|
||||
<programlisting>
|
||||
typedef struct AttInMetadata
|
||||
{
|
||||
@ -1538,70 +1540,80 @@ typedef struct AttInMetadata
|
||||
int32 *atttypmods;
|
||||
} AttInMetadata;
|
||||
</programlisting>
|
||||
To assist you in populating this struct, several functions and a macro
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To assist you in populating this structure, several functions and a macro
|
||||
are available. Use
|
||||
<programlisting>
|
||||
TupleDesc RelationNameGetTupleDesc(const char *relname)
|
||||
</programlisting>
|
||||
to get a TupleDesc based on a specified relation, or
|
||||
to get a <structname>TupleDesc</> based on a specified relation, or
|
||||
<programlisting>
|
||||
TupleDesc TypeGetTupleDesc(Oid typeoid, List *colaliases)
|
||||
</programlisting>
|
||||
to get a TupleDesc based on a type OID. This can be used to
|
||||
get a TupleDesc for a base (scalar) or composite (relation) type. Then
|
||||
to get a <structname>TupleDesc</> based on a type OID. This can
|
||||
be used to get a <structname>TupleDesc</> for a base (scalar) or
|
||||
composite (relation) type. Then
|
||||
<programlisting>
|
||||
AttInMetadata *TupleDescGetAttInMetadata(TupleDesc tupdesc)
|
||||
</programlisting>
|
||||
will return a pointer to an AttInMetadata struct, initialized based on
|
||||
the given TupleDesc. AttInMetadata can be used in conjunction with
|
||||
C strings to produce a properly formed tuple. The metadata is stored here
|
||||
to avoid redundant work across multiple calls.
|
||||
will return a pointer to an <structname>AttInMetadata</>,
|
||||
initialized based on the given
|
||||
<structname>TupleDesc</>. <structname>AttInMetadata</> can be
|
||||
used in conjunction with C strings to produce a properly formed
|
||||
tuple. The metadata is stored here to avoid redundant work across
|
||||
multiple calls.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To return a tuple you must create a tuple slot based on the
|
||||
TupleDesc. You can use
|
||||
<structname>TupleDesc</>. You can use
|
||||
<programlisting>
|
||||
TupleTableSlot *TupleDescGetSlot(TupleDesc tupdesc)
|
||||
</programlisting>
|
||||
to initialize this tuple slot, or obtain one through other (user provided)
|
||||
means. The tuple slot is needed to create a Datum for return by the
|
||||
means. The tuple slot is needed to create a <type>Datum</> for return by the
|
||||
function. The same slot can (and should) be re-used on each call.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After constructing an AttInMetadata structure,
|
||||
After constructing an <structname>AttInMetadata</> structure,
|
||||
<programlisting>
|
||||
HeapTuple BuildTupleFromCStrings(AttInMetadata *attinmeta, char **values)
|
||||
</programlisting>
|
||||
can be used to build a HeapTuple given user data in C string form.
|
||||
"values" is an array of C strings, one for each attribute of the return
|
||||
tuple. Each C string should be in the form expected by the input function
|
||||
of the attribute data type. In order to return a NULL value for
|
||||
one of the attributes, the corresponding pointer in the "values" array
|
||||
should be set to NULL. This function will need to be called again
|
||||
for each tuple you return.
|
||||
can be used to build a <structname>HeapTuple</> given user data
|
||||
in C string form. "values" is an array of C strings, one for
|
||||
each attribute of the return tuple. Each C string should be in
|
||||
the form expected by the input function of the attribute data
|
||||
type. In order to return a null value for one of the attributes,
|
||||
the corresponding pointer in the <parameter>values</> array
|
||||
should be set to <symbol>NULL</>. This function will need to
|
||||
be called again for each tuple you return.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Building a tuple via TupleDescGetAttInMetadata and BuildTupleFromCStrings
|
||||
is only convenient if your function naturally computes the values to
|
||||
be returned as text strings. If your code naturally computes the
|
||||
values as a set of Datums, you should instead use the underlying
|
||||
heap_formtuple routine to convert the Datums directly into a tuple.
|
||||
You will still need the TupleDesc and a TupleTableSlot, but not
|
||||
AttInMetadata.
|
||||
Building a tuple via <function>TupleDescGetAttInMetadata</> and
|
||||
<function>BuildTupleFromCStrings</> is only convenient if your
|
||||
function naturally computes the values to be returned as text
|
||||
strings. If your code naturally computes the values as a set of
|
||||
Datums, you should instead use the underlying
|
||||
<function>heap_formtuple</> routine to convert the
|
||||
<type>Datum</type>s directly into a tuple. You will still need
|
||||
the <structname>TupleDesc</> and a <structname>TupleTableSlot</>,
|
||||
but not <structname>AttInMetadata</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once you have built a tuple to return from your function, the tuple must
|
||||
be converted into a Datum. Use
|
||||
be converted into a <type>Datum</>. Use
|
||||
<programlisting>
|
||||
TupleGetDatum(TupleTableSlot *slot, HeapTuple tuple)
|
||||
</programlisting>
|
||||
to get a Datum given a tuple and a slot. This Datum can be returned
|
||||
directly if you intend to return just a single row, or it can be used
|
||||
as the current return value in a set-returning function.
|
||||
to get a <type>Datum</> given a tuple and a slot. This
|
||||
<type>Datum</> can be returned directly if you intend to return
|
||||
just a single row, or it can be used as the current return value
|
||||
in a set-returning function.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1614,12 +1626,14 @@ TupleGetDatum(TupleTableSlot *slot, HeapTuple tuple)
|
||||
<title>Returning Sets</title>
|
||||
|
||||
<para>
|
||||
A set-returning function (SRF) is normally called once for each item it
|
||||
returns. The SRF must therefore save enough state to remember what it
|
||||
was doing and return the next item on each call. The Table Function API
|
||||
provides the FuncCallContext struct to help control this process.
|
||||
<literal>fcinfo->flinfo->fn_extra</> is used to
|
||||
hold a pointer to FuncCallContext across calls.
|
||||
A set-returning function (<acronym>SRF</>) is normally called
|
||||
once for each item it returns. The <acronym>SRF</> must
|
||||
therefore save enough state to remember what it was doing and
|
||||
return the next item on each call. The Table Function API
|
||||
provides the <structname>FuncCallContext</> structure to help
|
||||
control this process. <literal>fcinfo->flinfo->fn_extra</>
|
||||
is used to hold a pointer to <structname>FuncCallContext</>
|
||||
across calls.
|
||||
<programlisting>
|
||||
typedef struct
|
||||
{
|
||||
@ -1676,12 +1690,11 @@ typedef struct
|
||||
* of the SRF.
|
||||
*/
|
||||
MemoryContext multi_call_memory_ctx;
|
||||
|
||||
} FuncCallContext;
|
||||
</programlisting>
|
||||
An SRF uses several functions and macros that automatically manipulate
|
||||
the FuncCallContext struct (and expect to find it via
|
||||
<literal>fn_extra</>). Use
|
||||
An <acronym>SRF</> uses several functions and macros that
|
||||
automatically manipulate the <structname>FuncCallContext</>
|
||||
structure (and expect to find it via <literal>fn_extra</>). Use
|
||||
<programlisting>
|
||||
SRF_IS_FIRSTCALL()
|
||||
</programlisting>
|
||||
@ -1690,13 +1703,14 @@ SRF_IS_FIRSTCALL()
|
||||
<programlisting>
|
||||
SRF_FIRSTCALL_INIT()
|
||||
</programlisting>
|
||||
to initialize the FuncCallContext struct. On every function call,
|
||||
to initialize the <structname>FuncCallContext</>. On every function call,
|
||||
including the first, use
|
||||
<programlisting>
|
||||
SRF_PERCALL_SETUP()
|
||||
</programlisting>
|
||||
to properly set up for using the FuncCallContext struct and clearing
|
||||
any previously returned data left over from the previous pass.
|
||||
to properly set up for using the <structname>FuncCallContext</>
|
||||
and clearing any previously returned data left over from the
|
||||
previous pass.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1704,24 +1718,25 @@ SRF_PERCALL_SETUP()
|
||||
<programlisting>
|
||||
SRF_RETURN_NEXT(funcctx, result)
|
||||
</programlisting>
|
||||
to return it to the caller. (The <literal>result</>
|
||||
must be a Datum, either a single value or a tuple prepared as described
|
||||
earlier.) Finally, when your function is finished returning data, use
|
||||
to return it to the caller. (The <literal>result</> must be a
|
||||
<type>Datum</>, either a single value or a tuple prepared as
|
||||
described earlier.) Finally, when your function is finished
|
||||
returning data, use
|
||||
<programlisting>
|
||||
SRF_RETURN_DONE(funcctx)
|
||||
</programlisting>
|
||||
to clean up and end the SRF.
|
||||
to clean up and end the <acronym>SRF</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The palloc memory context that is current when the SRF is called is
|
||||
The memory context that is current when the <acronym>SRF</> is called is
|
||||
a transient context that will be cleared between calls. This means
|
||||
that you do not need to be careful about pfree'ing everything
|
||||
you palloc; it will go away anyway. However, if you want to allocate
|
||||
that you do not need to <function>pfree</> everything
|
||||
you <function>palloc</>; it will go away anyway. However, if you want to allocate
|
||||
any data structures to live across calls, you need to put them somewhere
|
||||
else. The memory context referenced by
|
||||
<structfield>multi_call_memory_ctx</> is a suitable location for any
|
||||
data that needs to survive until the SRF is finished running. In most
|
||||
data that needs to survive until the <acronym>SRF</> is finished running. In most
|
||||
cases, this means that you should switch into
|
||||
<structfield>multi_call_memory_ctx</> while doing the first-call setup.
|
||||
</para>
|
||||
@ -1776,7 +1791,7 @@ my_Set_Returning_Function(PG_FUNCTION_ARGS)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A complete example of a simple SRF returning a composite type looks like:
|
||||
A complete example of a simple <acronym>SRF</> returning a composite type looks like:
|
||||
<programlisting>
|
||||
PG_FUNCTION_INFO_V1(testpassbyval);
|
||||
Datum
|
||||
@ -1882,7 +1897,7 @@ CREATE OR REPLACE FUNCTION testpassbyval(int4, int4) RETURNS setof __testpassbyv
|
||||
</para>
|
||||
|
||||
<para>
|
||||
See contrib/tablefunc for more examples of Table Functions.
|
||||
See <filename>contrib/tablefunc</> for more examples of table functions.
|
||||
</para>
|
||||
|
||||
</sect3>
|
||||
@ -1897,7 +1912,7 @@ CREATE OR REPLACE FUNCTION testpassbyval(int4, int4) RETURNS setof __testpassbyv
|
||||
programming language functions. Be warned: this section
|
||||
of the manual will not make you a programmer. You must
|
||||
have a good understanding of <acronym>C</acronym>
|
||||
(including the use of pointers and the malloc memory manager)
|
||||
(including the use of pointers)
|
||||
before trying to write <acronym>C</acronym> functions for
|
||||
use with <productname>PostgreSQL</productname>. While it may
|
||||
be possible to load functions written in languages other
|
||||
@ -2183,15 +2198,15 @@ WHERE proname LIKE 'bytea%';
|
||||
<para>
|
||||
The call handler is called in the same way as any other function:
|
||||
It receives a pointer to a
|
||||
<structname>FunctionCallInfoData</structname> struct containing
|
||||
<structname>FunctionCallInfoData</structname> <type>struct</> containing
|
||||
argument values and information about the called function, and it
|
||||
is expected to return a <type>Datum</type> result (and possibly
|
||||
set the <structfield>isnull</structfield> field of the
|
||||
<structname>FunctionCallInfoData</structname> struct, if it wishes
|
||||
<structname>FunctionCallInfoData</structname> structure, if it wishes
|
||||
to return an SQL NULL result). The difference between a call
|
||||
handler and an ordinary callee function is that the
|
||||
<structfield>flinfo->fn_oid</structfield> field of the
|
||||
<structname>FunctionCallInfoData</structname> struct will contain
|
||||
<structname>FunctionCallInfoData</structname> structure will contain
|
||||
the OID of the actual function to be called, not of the call
|
||||
handler itself. The call handler must use this field to determine
|
||||
which function to execute. Also, the passed argument list has
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.28 2002/07/30 17:34:37 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.29 2002/09/21 18:32:54 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -16,7 +16,7 @@ PostgreSQL documentation
|
||||
over a new type, nor associate operators of a new type with secondary
|
||||
indexes.
|
||||
To do these things, we must define an <firstterm>operator class</>
|
||||
for the new datatype. We will describe operator classes in the
|
||||
for the new data type. We will describe operator classes in the
|
||||
context of a running example: a new operator
|
||||
class for the B-tree access method that stores and
|
||||
sorts complex numbers in ascending absolute value order.
|
||||
@ -25,7 +25,7 @@ PostgreSQL documentation
|
||||
<note>
|
||||
<para>
|
||||
Prior to <productname>PostgreSQL</productname> release 7.3, it was
|
||||
necesssary to make manual additions to
|
||||
necessary to make manual additions to
|
||||
<classname>pg_amop</>, <classname>pg_amproc</>, and
|
||||
<classname>pg_opclass</> in order to create a user-defined
|
||||
operator class. That approach is now deprecated in favor of
|
||||
@ -55,7 +55,7 @@ PostgreSQL documentation
|
||||
access method needs to be able to use to work with a particular data type.
|
||||
Operator classes are so called because one thing they specify is the set
|
||||
of WHERE-clause operators that can be used with an index (ie, can be
|
||||
converted into an indexscan qualification). An operator class may also
|
||||
converted into an index scan qualification). An operator class may also
|
||||
specify some <firstterm>support procedures</> that are needed by the
|
||||
internal operations of the index access method, but do not directly
|
||||
correspond to any WHERE-clause operator that can be used with the index.
|
||||
@ -63,16 +63,16 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
It is possible to define multiple operator classes for the same
|
||||
input datatype and index access method. By doing this, multiple
|
||||
sets of indexing semantics can be defined for a single datatype.
|
||||
input data type and index access method. By doing this, multiple
|
||||
sets of indexing semantics can be defined for a single data type.
|
||||
For example, a B-tree index requires a sort ordering to be defined
|
||||
for each datatype it works on.
|
||||
It might be useful for a complex-number datatype
|
||||
for each data type it works on.
|
||||
It might be useful for a complex-number data type
|
||||
to have one B-tree operator class that sorts the data by complex
|
||||
absolute value, another that sorts by real part, and so on.
|
||||
Typically one of the operator classes will be deemed most commonly
|
||||
useful and will be marked as the default operator class for that
|
||||
datatype and index access method.
|
||||
data type and index access method.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -101,7 +101,7 @@ PostgreSQL documentation
|
||||
comparison it is. Instead, the index access method defines a set of
|
||||
<quote>strategies</>, which can be thought of as generalized operators.
|
||||
Each operator class shows which actual operator corresponds to each
|
||||
strategy for a particular datatype and interpretation of the index
|
||||
strategy for a particular data type and interpretation of the index
|
||||
semantics.
|
||||
</para>
|
||||
|
||||
@ -240,7 +240,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
In short, an operator class must specify a set of operators that express
|
||||
each of these semantic ideas for the operator class's datatype.
|
||||
each of these semantic ideas for the operator class's data type.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -262,7 +262,7 @@ PostgreSQL documentation
|
||||
|
||||
<para>
|
||||
Just as with operators, the operator class identifies which specific
|
||||
functions should play each of these roles for a given datatype and
|
||||
functions should play each of these roles for a given data type and
|
||||
semantic interpretation. The index access method specifies the set
|
||||
of functions it needs, and the operator class identifies the correct
|
||||
functions to use by assigning <quote>support function numbers</> to them.
|
||||
@ -572,7 +572,7 @@ CREATE OPERATOR CLASS complex_abs_ops
|
||||
<programlisting>
|
||||
OPERATOR 1 < (complex, complex) ,
|
||||
</programlisting>
|
||||
but there is no need to do so when the operators take the same datatype
|
||||
but there is no need to do so when the operators take the same data type
|
||||
we are defining the operator class for.
|
||||
</para>
|
||||
|
||||
@ -631,9 +631,9 @@ CREATE OPERATOR CLASS polygon_ops
|
||||
</programlisting>
|
||||
|
||||
At present, only the GiST access method supports a
|
||||
<literal>STORAGE</> type that's different from the column datatype.
|
||||
<literal>STORAGE</> type that's different from the column data type.
|
||||
The GiST <literal>compress</> and <literal>decompress</> support
|
||||
routines must deal with datatype conversion when <literal>STORAGE</>
|
||||
routines must deal with data-type conversion when <literal>STORAGE</>
|
||||
is used.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.19 2002/05/11 02:09:41 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.20 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="xoper">
|
||||
@ -200,9 +200,9 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
|
||||
<para>
|
||||
Providing a negator is very helpful to the query optimizer since
|
||||
it allows expressions like NOT (x = y) to be simplified into
|
||||
it allows expressions like <literal>NOT (x = y)</> to be simplified into
|
||||
x <> y. This comes up more often than you might think, because
|
||||
NOTs can be inserted as a consequence of other rearrangements.
|
||||
<literal>NOT</> operations can be inserted as a consequence of other rearrangements.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -378,14 +378,14 @@ table1.column1 OP table2.column2
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>MERGES (SORT1, SORT2, LTCMP, GTCMP)</title>
|
||||
<title><literal>MERGES</> (<literal>SORT1</>, <literal>SORT2</>, <literal>LTCMP</>, <literal>GTCMP</>)</title>
|
||||
|
||||
<para>
|
||||
The <literal>MERGES</literal> clause, if present, tells the system that
|
||||
it is permissible to use the merge join method for a join based on this
|
||||
operator. <literal>MERGES</> only makes sense for binary operators that
|
||||
return <literal>boolean</>, and in practice the operator must represent
|
||||
equality for some datatype or pair of datatypes.
|
||||
equality for some data type or pair of data types.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -400,19 +400,19 @@ table1.column1 OP table2.column2
|
||||
it is possible to merge-join two
|
||||
distinct data types so long as they are logically compatible. For
|
||||
example, the <type>int2</type>-versus-<type>int4</type> equality operator
|
||||
is mergejoinable.
|
||||
is merge-joinable.
|
||||
We only need sorting operators that will bring both data types into a
|
||||
logically compatible sequence.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Execution of a merge join requires that the system be able to identify
|
||||
four operators related to the mergejoin equality operator: less-than
|
||||
comparison for the left input datatype, less-than comparison for the
|
||||
right input datatype, less-than comparison between the two datatypes, and
|
||||
greater-than comparison between the two datatypes. (These are actually
|
||||
four distinct operators if the mergejoinable operator has two different
|
||||
input datatypes; but when the input types are the same the three
|
||||
four operators related to the merge-join equality operator: less-than
|
||||
comparison for the left input data type, less-than comparison for the
|
||||
right input data type, less-than comparison between the two data types, and
|
||||
greater-than comparison between the two data types. (These are actually
|
||||
four distinct operators if the merge-joinable operator has two different
|
||||
input data types; but when the input types are the same the three
|
||||
less-than operators are all the same operator.)
|
||||
It is possible to
|
||||
specify these operators individually by name, as the <literal>SORT1</>,
|
||||
@ -426,8 +426,8 @@ table1.column1 OP table2.column2
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The input datatypes of the four comparison operators can be deduced
|
||||
from the input types of the mergejoinable operator, so just as with
|
||||
The input data types of the four comparison operators can be deduced
|
||||
from the input types of the merge-joinable operator, so just as with
|
||||
<literal>COMMUTATOR</>, only the operator names need be given in these
|
||||
clauses. Unless you are using peculiar choices of operator names,
|
||||
it's sufficient to write <literal>MERGES</> and let the system fill in
|
||||
@ -440,14 +440,14 @@ table1.column1 OP table2.column2
|
||||
|
||||
<para>
|
||||
There are additional restrictions on operators that you mark
|
||||
mergejoinable. These restrictions are not currently checked by
|
||||
merge-joinable. These restrictions are not currently checked by
|
||||
<command>CREATE OPERATOR</command>, but errors may occur when
|
||||
the operator is used if any are not true:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
A mergejoinable equality operator must have a mergejoinable
|
||||
A merge-joinable equality operator must have a merge-joinable
|
||||
commutator (itself if the two data types are the same, or a related
|
||||
equality operator if they are different).
|
||||
</para>
|
||||
@ -455,10 +455,10 @@ table1.column1 OP table2.column2
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
If there is a mergejoinable operator relating any two data types
|
||||
A and B, and another mergejoinable operator relating B to any
|
||||
third data type C, then A and C must also have a mergejoinable
|
||||
operator; in other words, having a mergejoinable operator must
|
||||
If there is a merge-joinable operator relating any two data types
|
||||
A and B, and another merge-joinable operator relating B to any
|
||||
third data type C, then A and C must also have a merge-joinable
|
||||
operator; in other words, having a merge-joinable operator must
|
||||
be transitive.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -476,7 +476,7 @@ table1.column1 OP table2.column2
|
||||
<para>
|
||||
In <ProductName>PostgreSQL</ProductName> versions before 7.3,
|
||||
the <literal>MERGES</> shorthand was not available: to make a
|
||||
mergejoinable operator one had to write both <literal>SORT1</> and
|
||||
merge-joinable operator one had to write both <literal>SORT1</> and
|
||||
<literal>SORT2</> explicitly. Also, the <literal>LTCMP</> and
|
||||
<literal>GTCMP</>
|
||||
options did not exist; the names of those operators were hardwired as
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.18 2002/08/22 00:01:40 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v 1.19 2002/09/21 18:32:54 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xplang">
|
||||
@ -122,10 +122,10 @@ CREATE <optional>TRUSTED</optional> <optional>PROCEDURAL</optional> LANGUAGE <re
|
||||
In a default <productname>PostgreSQL</productname> installation,
|
||||
the handler for the <application>PL/pgSQL</application> language
|
||||
is built and installed into the <quote>library</quote>
|
||||
directory. If Tcl/Tk support is configured in, the handlers for
|
||||
PL/Tcl and PL/TclU are also built and installed in the same
|
||||
location. Likewise, the PL/Perl and PL/PerlU handlers are built
|
||||
and installed if Perl support is configured, and PL/Python is
|
||||
directory. If <application>Tcl/Tk</> support is configured in, the handlers for
|
||||
<application>PL/Tcl</> and <application>PL/TclU</> are also built and installed in the same
|
||||
location. Likewise, the <application>PL/Perl</> and <application>PL/PerlU</> handlers are built
|
||||
and installed if Perl support is configured, and <application>PL/Python</> is
|
||||
installed if Python support is configured. The
|
||||
<filename>createlang</filename> script automates <xref
|
||||
linkend="xplang-install-cr1"> and <xref
|
||||
|
Reference in New Issue
Block a user