mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-02-05 19:09:58 +08:00
Add some more index entries.
This commit is contained in:
Peter Eisentraut
parent
3a306eefe9
commit
3c879e3738
@ -1,7 +1,9 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.17 2001/10/04 04:46:43 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.18 2001/11/12 19:19:39 petere Exp $ -->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
|
||||
<indexterm zone="backup"><primary>backup</></>
|
||||
|
||||
<para>
|
||||
As everything that contains valuable data, <productname>Postgres</>
|
||||
databases should be backed up regularly. While the procedure is
|
||||
@ -363,6 +365,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
|
||||
<sect1 id="migration">
|
||||
<title>Migration between releases</title>
|
||||
<indexterm zone="migration"><primary>upgrading</></>
|
||||
|
||||
<para>
|
||||
As a general rule, the internal data storage format is subject to
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.13 2001/10/31 20:35:01 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.14 2001/11/12 19:19:39 petere Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
@ -49,6 +49,8 @@
|
||||
<sect1 id="locale">
|
||||
<title>Locale Support</title>
|
||||
|
||||
<indexterm zone="locale"><primary>locale</></>
|
||||
|
||||
<para>
|
||||
<firstterm>Locale</> support refers to an application respecting
|
||||
cultural preferences regarding alphabets, sorting, number
|
||||
@ -171,6 +173,7 @@ export LANG=sv_SE
|
||||
<listitem>
|
||||
<para>
|
||||
Sort order in <command>ORDER BY</> queries.
|
||||
<indexterm><primary>ORDER BY</></>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -243,6 +246,8 @@ perl: warning: Falling back to the standard locale ("C").
|
||||
<sect1 id="multibyte">
|
||||
<title>Multibyte Support</title>
|
||||
|
||||
<indexterm zone="multibyte"><primary>multibyte</></>
|
||||
|
||||
<note>
|
||||
<title>Author</title>
|
||||
|
||||
@ -586,6 +591,8 @@ RESET CLIENT_ENCODING;
|
||||
<sect2>
|
||||
<title>About Unicode</title>
|
||||
|
||||
<indexterm><primary>Unicode</></>
|
||||
|
||||
<para>
|
||||
An automatic encoding translation between Unicode and other
|
||||
encodings has been supported since PostgreSQL 7.1.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.25 2001/11/12 02:35:16 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v 1.26 2001/11/12 19:19:39 petere Exp $ -->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
<title>Client Authentication</title>
|
||||
@ -423,12 +423,15 @@ host all 192.168.0.0 255.255.0.0 ident omicron
|
||||
The following describes the authentication methods in detail.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<sect2 id="auth-password">
|
||||
<title>Password authentication</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>password</primary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>MD5</>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>Postgres</> database passwords are separate from any
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.15 2001/10/26 19:58:12 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.16 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<sect2 id="dfunc">
|
||||
@ -25,6 +25,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.15 2001/10/26 19:58:12 tgl E
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>PIC</></>
|
||||
Creating shared libraries is generally analoguous to linking
|
||||
executables: first the source files are compiled into object files,
|
||||
then the object files are linked together. The object files need to
|
||||
@ -57,6 +58,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/dfunc.sgml,v 1.15 2001/10/26 19:58:12 tgl E
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><productname>BSD/OS</productname></term>
|
||||
<indexterm><primary>BSD/OS</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -74,6 +76,7 @@ ld -shared -o foo.so foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>FreeBSD</productname></term>
|
||||
<indexterm><primary>FreeBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -91,6 +94,7 @@ gcc -shared -o foo.so foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>HP-UX</productname></term>
|
||||
<indexterm><primary>HP-UX</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag of the system compiler to create
|
||||
@ -117,6 +121,7 @@ ld -b -o foo.sl foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Irix</productname></term>
|
||||
<indexterm><primary>Irix</></>
|
||||
<listitem>
|
||||
<para>
|
||||
<acronym>PIC</acronym> is the default, no special compiler
|
||||
@ -132,6 +137,7 @@ ld -shared -o foo.so foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Linux</productname></term>
|
||||
<indexterm><primary>Linux</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -150,6 +156,7 @@ cc -shared -o foo.so foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>NetBSD</productname></term>
|
||||
<indexterm><primary>NetBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -167,6 +174,7 @@ gcc -shared -o foo.so foo.o
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>OpenBSD</productname></term>
|
||||
<indexterm><primary>OpenBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -180,26 +188,9 @@ ld -Bshareable -o foo.so foo.o
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Digital Unix/Tru64 UNIX</term>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<acronym>PIC</acronym> is the default, so the compilation command
|
||||
is the usual one. <command>ld</command> with special options is
|
||||
used to do the linking:
|
||||
<programlisting>
|
||||
cc -c foo.c
|
||||
ld -shared -expect_unresolved '*' -o foo.so foo.o
|
||||
</programlisting>
|
||||
The same procedure is used with GCC instead of the system
|
||||
compiler; no special options are required.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Solaris</productname></term>
|
||||
<indexterm><primary>Solaris</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is
|
||||
@ -221,8 +212,28 @@ gcc -G -o foo.so foo.o
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Tru64 UNIX</term>
|
||||
<indexterm><primary>Tru64 UNIX</></>
|
||||
<indexterm><primary>Digital UNIX</><see>Tru64 UNIX</></>
|
||||
<listitem>
|
||||
<para>
|
||||
<acronym>PIC</acronym> is the default, so the compilation command
|
||||
is the usual one. <command>ld</command> with special options is
|
||||
used to do the linking:
|
||||
<programlisting>
|
||||
cc -c foo.c
|
||||
ld -shared -expect_unresolved '*' -o foo.so foo.o
|
||||
</programlisting>
|
||||
The same procedure is used with GCC instead of the system
|
||||
compiler; no special options are required.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><productname>Unixware</productname></term>
|
||||
<indexterm><primary>Unixware</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The compiler flag to create <acronym>PIC</acronym> is <option>-K
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.29 2001/11/08 23:37:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.30 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="ecpg">
|
||||
@ -28,6 +28,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.29 2001/11/08 23:37:50 petere
|
||||
<title><application>ecpg</application> - Embedded <acronym>SQL</acronym>
|
||||
in <acronym>C</acronym></title>
|
||||
|
||||
<indexterm zone="ecpg"><primary>embedded SQL</primary><secondary>in C</secondary></indexterm>
|
||||
|
||||
<para>
|
||||
This describes the embedded <acronym>SQL</acronym> package for
|
||||
<productname>Postgres</productname>. It works with
|
||||
@ -538,6 +540,7 @@ struct sqlca
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Syntax of FETCH</term>
|
||||
<indexterm><primary>FETCH</><secondary>embedded SQL</></indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
The standard syntax for FETCH is:
|
||||
@ -546,7 +549,8 @@ struct sqlca
|
||||
FETCH [direction] [amount] IN|FROM <replaceable>cursor</replaceable>.
|
||||
</para>
|
||||
<para>
|
||||
<application>ORACLE</application>, however, does not use the keywords IN
|
||||
<indexterm><primary>Oracle</></>
|
||||
<application>Oracle</application>, however, does not use the keywords IN
|
||||
or FROM. This feature cannot be added since it would create parsing
|
||||
conflicts.
|
||||
</para>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.74 2001/10/31 20:39:30 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.75 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
@ -70,7 +70,7 @@ PGconn *PQconnectdb(const char *conninfo)
|
||||
This routine opens a new database connection using the parameters taken
|
||||
from the string <literal>conninfo</literal>. Unlike <function>PQsetdbLogin</> below,
|
||||
the parameter set can be extended without changing the function signature,
|
||||
so use either of this routine or the non-blocking analogues <function>PQconnectStart</>
|
||||
so use either of this routine or the nonblocking analogues <function>PQconnectStart</>
|
||||
and <function>PQconnectPoll</function> is preferred for application programming. The passed string
|
||||
can be empty to use all default parameters, or it can contain one or more
|
||||
parameter settings separated by whitespace.
|
||||
@ -106,7 +106,7 @@ PGconn *PQconnectdb(const char *conninfo)
|
||||
<para>
|
||||
IP address of host to connect to. This should be in standard
|
||||
numbers-and-dots form, as used by the BSD functions <function>inet_aton</> et al. If
|
||||
a non-zero-length string is specified, TCP/IP communication is used.
|
||||
a nonzero-length string is specified, TCP/IP communication is used.
|
||||
</para>
|
||||
<para>
|
||||
Using <literal>hostaddr</> instead of host allows the application to avoid a host
|
||||
@ -244,7 +244,8 @@ PGconn *PQsetdb(char *pghost,
|
||||
<para>
|
||||
<function>PQconnectStart</function>,
|
||||
<function>PQconnectPoll</function>
|
||||
Make a connection to the database server in a non-blocking manner.
|
||||
<indexterm><primary>nonblocking connection</primary></indexterm>
|
||||
Make a connection to the database server in a nonblocking manner.
|
||||
<synopsis>
|
||||
PGconn *PQconnectStart(const char *conninfo)
|
||||
</synopsis>
|
||||
@ -289,7 +290,7 @@ PostgresPollingStatusType PQconnectPoll(PGconn *conn)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To begin, call <literal>conn=PQconnectStart("<connection_info_string>")</literal>.
|
||||
To begin, call <literal>conn=PQconnectStart("<replaceable>connection_info_string</>")</literal>.
|
||||
If <varname>conn</varname> is NULL, then <application>libpq</> has been unable to allocate a new <structname>PGconn</>
|
||||
structure. Otherwise, a valid <structname>PGconn</> pointer is returned (though not yet
|
||||
representing a valid connection to the database). On return from
|
||||
@ -413,7 +414,7 @@ switch(PQstatus(conn))
|
||||
</para>
|
||||
|
||||
<para>
|
||||
These functions leave the socket in a non-blocking state as if
|
||||
These functions leave the socket in a nonblocking state as if
|
||||
<function>PQsetnonblocking</function> had been called.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -495,7 +496,7 @@ void PQreset(PGconn *conn)
|
||||
<para>
|
||||
<function>PQresetStart</function>
|
||||
<function>PQresetPoll</function>
|
||||
Reset the communication port with the backend, in a non-blocking manner.
|
||||
Reset the communication port with the backend, in a nonblocking manner.
|
||||
<synopsis>
|
||||
int PQresetStart(PGconn *conn);
|
||||
</synopsis>
|
||||
@ -506,7 +507,7 @@ PostgresPollingStatusType PQresetPoll(PGconn *conn);
|
||||
reestablish a new connection to the same postmaster, using all the same
|
||||
parameters previously used. This may be useful for error recovery if a
|
||||
working connection is lost. They differ from <function>PQreset</function> (above) in that they
|
||||
act in a non-blocking manner. These functions suffer from the same
|
||||
act in a nonblocking manner. These functions suffer from the same
|
||||
restrictions as <function>PQconnectStart</> and <function>PQconnectPoll</>.
|
||||
</para>
|
||||
<para>
|
||||
@ -520,6 +521,8 @@ PostgresPollingStatusType PQresetPoll(PGconn *conn);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>libpq-fe.h</></>
|
||||
<indexterm><primary>libpq-int.h</></>
|
||||
<application>libpq</application> application programmers should be careful to
|
||||
maintain the <structname>PGconn</structname> abstraction. Use the accessor functions below to get
|
||||
at the contents of <structname>PGconn</structname>. Avoid directly referencing the fields of the
|
||||
@ -529,6 +532,7 @@ definition of struct <structname>PGconn</structname> is not even provided in <fi
|
||||
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.)
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -640,6 +644,7 @@ ConnStatusType PQstatus(const PGconn *conn)
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQerrorMessage</function>
|
||||
<indexterm><primary>error message</></>
|
||||
Returns the error message most recently generated by
|
||||
an operation on the connection.
|
||||
<synopsis>
|
||||
@ -677,6 +682,7 @@ int PQbackendPID(const PGconn *conn);
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQgetssl</function>
|
||||
<indexterm><primary>SSL</></>
|
||||
Returns the SSL structure used in the connection, or NULL
|
||||
if SSL is not in use.
|
||||
<synopsis>
|
||||
@ -858,30 +864,33 @@ as with a <structname>PGresult</structname> returned by <application>libpq</appl
|
||||
|
||||
<sect2 id="libpq-exec-escape-string">
|
||||
<title>Escaping strings for inclusion in SQL queries</title>
|
||||
|
||||
<indexterm zone="libpq-exec-escape-string"><primary>escaping strings</></>
|
||||
|
||||
<para>
|
||||
<function>PQescapeString</function>
|
||||
Escapes a string for use within an SQL query.
|
||||
<synopsis>
|
||||
size_t PQescapeString (char *to, const char *from, size_t length);
|
||||
</synopsis>
|
||||
If you want to include strings which have been received
|
||||
from a source which is not trustworthy (for example, because they were
|
||||
If you want to include strings that have been received
|
||||
from a source that is not trustworthy (for example, because they were
|
||||
transmitted across a network), you cannot directly include them in SQL
|
||||
queries for security reasons. Instead, you have to quote special
|
||||
characters which are otherwise interpreted by the SQL parser.
|
||||
characters that are otherwise interpreted by the SQL parser.
|
||||
</para>
|
||||
<para>
|
||||
<function>PQescapeString</> performs this operation. The
|
||||
<parameter>from</> points to the first character of the string which
|
||||
<parameter>from</> points to the first character of the string that
|
||||
is to be escaped, and the <parameter>length</> parameter counts the
|
||||
number of characters in this string (a terminating NUL character is
|
||||
neither necessary nor counted). <parameter>to</> shall point to a
|
||||
buffer which is able to hold at least one more character than twice
|
||||
buffer that is able to hold at least one more character than twice
|
||||
the value of <parameter>length</>, otherwise the behavior is
|
||||
undefined. A call to <function>PQescapeString</> writes an escaped
|
||||
version of the <parameter>from</> string to the <parameter>to</>
|
||||
buffer, replacing special characters so that they cannot cause any
|
||||
harm, and adding a terminating NUL character. The single quotes which
|
||||
harm, and adding a terminating NUL character. The single quotes that
|
||||
must surround PostgreSQL string literals are not part of the result
|
||||
string.
|
||||
</para>
|
||||
@ -1175,6 +1184,8 @@ and is not thread-safe.
|
||||
<sect1 id="libpq-async">
|
||||
<title>Asynchronous Query Processing</title>
|
||||
|
||||
<indexterm zone="libpq-async"><primary>nonblocking connection</></>
|
||||
|
||||
<para>
|
||||
The <function>PQexec</function> function is adequate for submitting queries in
|
||||
simple synchronous
|
||||
@ -1220,7 +1231,7 @@ was added.
|
||||
<para>
|
||||
Old applications can neglect to use <function>PQsetnonblocking</function>
|
||||
and get the older potentially blocking behavior. Newer programs can use
|
||||
<function>PQsetnonblocking</function> to achieve a completely non-blocking
|
||||
<function>PQsetnonblocking</function> to achieve a completely nonblocking
|
||||
connection to the backend.
|
||||
|
||||
<itemizedlist>
|
||||
@ -1260,7 +1271,7 @@ int PQsetnonblocking(PGconn *conn, int arg)
|
||||
<synopsis>
|
||||
int PQisnonblocking(const PGconn *conn)
|
||||
</synopsis>
|
||||
Returns 1 if the connection is set to non-blocking mode,
|
||||
Returns 1 if the connection is set to nonblocking mode,
|
||||
0 if blocking.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1368,7 +1379,7 @@ some reason.
|
||||
<synopsis>
|
||||
int PQflush(PGconn *conn);
|
||||
</synopsis>
|
||||
<function>PQflush</function> needs to be called on a non-blocking connection
|
||||
<function>PQflush</function> needs to be called on a nonblocking connection
|
||||
before calling <function>select</function> to determine if a response has
|
||||
arrived. If 0 is returned it ensures that there is no data queued to the
|
||||
backend that has not actually been sent. Only applications that have used
|
||||
@ -1395,7 +1406,7 @@ data; after which, <function>PQisBusy</function>, <function>PQgetResult</functio
|
||||
and/or <function>PQnotifies</function> can be used to process the response.
|
||||
</para>
|
||||
<para>
|
||||
Non-blocking connections (that have used <function>PQsetnonblocking</function>)
|
||||
Nonblocking connections (that have used <function>PQsetnonblocking</function>)
|
||||
should not use <function>select</function> until <function>PQflush</function>
|
||||
has returned 0 indicating that there is no buffered data waiting to be sent
|
||||
to the backend.
|
||||
@ -1525,6 +1536,8 @@ typedef struct {
|
||||
<sect1 id="libpq-notify">
|
||||
<title>Asynchronous Notification</title>
|
||||
|
||||
<indexterm zone="libpq-notify"><primary>NOTIFY</primary></indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> supports asynchronous notification via the
|
||||
<command>LISTEN</command> and <command>NOTIFY</command> commands. A backend registers its interest in a particular
|
||||
@ -1828,14 +1841,14 @@ void PQuntrace(PGconn *conn)
|
||||
</sect1>
|
||||
|
||||
<sect1 id="libpq-control">
|
||||
<title>
|
||||
<application>libpq</application> Control Functions</title>
|
||||
<title><application>libpq</application> Control Functions</title>
|
||||
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<function>PQsetNoticeProcessor</function>
|
||||
<indexterm><primary>notice processor</></>
|
||||
Control reporting of notice and warning messages generated by libpq.
|
||||
<synopsis>
|
||||
typedef void (*PQnoticeProcessor) (void *arg, const char *message);
|
||||
@ -2106,6 +2119,7 @@ CPPFLAGS += -I/usr/local/pgsql/include
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>pg_config</></>
|
||||
If there is any chance that your program might be compiled by
|
||||
other users then you should not hardcode the directory location
|
||||
like that. Instead, you can run the utility
|
||||
@ -2171,6 +2185,7 @@ testlibpq.o(.text+0xa4): undefined reference to `PQerrorMessage'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>libpq-int.h</></>
|
||||
If your codes references the header file
|
||||
<filename>libpq-int.h</filename> and you refuse to fix your code to
|
||||
not use it, starting in PostgreSQL 7.2, this file will be found in
|
||||
|
||||
@ -1,10 +1,13 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.23 2001/10/09 18:46:00 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.24 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="largeObjects">
|
||||
<title id="largeObjects-title">Large Objects</title>
|
||||
|
||||
<indexterm zone="largeobjects"><primary>large object</></>
|
||||
<indexterm><primary>BLOB</><see>large object</></>
|
||||
|
||||
<sect1 id="lo-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
@ -41,6 +44,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.23 2001/10/09 18:46:00 petere
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>TOAST</></>
|
||||
<indexterm><primary>sliced bread</><see>TOAST</></indexterm>
|
||||
<productname>PostgreSQL 7.1</productname> introduced a mechanism
|
||||
(nicknamed <quote><acronym>TOAST</acronym></quote>) that allows
|
||||
data rows to be much larger than individual data pages. This
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.5 2001/10/12 23:32:34 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.6 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -52,6 +52,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.5 2001/10/12 23:32:34
|
||||
<sect1 id="routine-vacuuming">
|
||||
<title>Routine Vacuuming</title>
|
||||
|
||||
<indexterm zone="routine-vacuuming">
|
||||
<primary>vacuum</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname>'s <command>VACUUM</> command must be
|
||||
run on a regular basis for several reasons:
|
||||
@ -93,6 +97,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.5 2001/10/12 23:32:34
|
||||
<sect2 id="vacuum-for-space-recovery">
|
||||
<title>Recovering disk space</title>
|
||||
|
||||
<indexterm zone="vacuum-for-space-recovery">
|
||||
<primary>disk space</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
In normal <productname>PostgreSQL</productname> operation, an UPDATE or
|
||||
DELETE of a row does not immediately remove the old <firstterm>tuple</>
|
||||
@ -219,6 +227,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.5 2001/10/12 23:32:34
|
||||
<sect2 id="vacuum-for-wraparound">
|
||||
<title>Preventing transaction ID wraparound failures</title>
|
||||
|
||||
<indexterm zone="vacuum-for-wraparound">
|
||||
<primary>transaction ID</primary>
|
||||
<secondary>wraparound</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname>'s MVCC transaction semantics
|
||||
depend on being able to compare transaction ID (<firstterm>XID</>)
|
||||
|
||||
@ -1,10 +1,12 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.16 2001/10/09 18:46:00 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.17 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="managing-databases">
|
||||
<title>Managing Databases</title>
|
||||
|
||||
<indexterm zone="managing-databases"><primary>database</></>
|
||||
|
||||
<para>
|
||||
A database is a named collection of SQL objects (<quote>database
|
||||
objects</quote>); every database object (tables, function, etc.)
|
||||
@ -53,7 +55,7 @@ CREATE DATABASE <replaceable>name</>
|
||||
</para>
|
||||
|
||||
<formalpara>
|
||||
<title>Bootstrapping</title>
|
||||
<title>Bootstrapping:</title>
|
||||
<para>
|
||||
Since you need to be connected to the database server in order to
|
||||
execute the <command>CREATE DATABASE</command> command, the
|
||||
@ -140,6 +142,7 @@ setenv PGDATA2 /home/postgres/data
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>initlocation</></>
|
||||
To create a data storage area in <envar>PGDATA2</>, ensure that
|
||||
<filename>/home/postgres</filename> already exists and is writable
|
||||
by the user account that runs the server (see <xref
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.3 2001/11/08 23:39:22 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.4 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="monitoring">
|
||||
@ -27,6 +27,11 @@ $Header: /cvsroot/pgsql/doc/src/sgml/monitoring.sgml,v 1.3 2001/11/08 23:39:22 p
|
||||
<sect1 id="monitoring-ps">
|
||||
<title>Standard Unix Tools</Title>
|
||||
|
||||
<indexterm zone="monitoring-ps">
|
||||
<primary>ps</primary>
|
||||
<secondary>to monitor activity</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
On most platforms, <productname>PostgreSQL</productname> modifies its
|
||||
command title as reported by <command>ps</>, so that individual server
|
||||
@ -72,6 +77,10 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<sect1 id="monitoring-stats">
|
||||
<title>Statistics Collector</Title>
|
||||
|
||||
<indexterm zone="monitoring-stats">
|
||||
<primary>statistics</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname>'s <firstterm>statistics collector</>
|
||||
is a subsystem that supports collection and reporting of information about
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.26 2001/10/31 20:39:30 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.27 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="odbc">
|
||||
@ -146,6 +146,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.26 2001/10/31 20:39:30
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>odbc.sql</></>
|
||||
Additionally, you should install the ODBC catalog extensions. That will
|
||||
provide a number of functions mandated by the ODBC standard that are not
|
||||
supplied by <productname>PostgreSQL</> by default. The file
|
||||
@ -166,6 +167,8 @@ psql -d template1 -f <replaceable>LOCATION</>/odbc.sql
|
||||
<sect1 id="odbc-config">
|
||||
<title>Configuration Files</title>
|
||||
|
||||
<indexterm zone="odbc-config"><primary>.odbc.ini</></>
|
||||
|
||||
<para>
|
||||
<filename>~/.odbc.ini</filename> contains user-specified access information
|
||||
for the <productname>psqlODBC</productname> driver.
|
||||
@ -308,7 +311,7 @@ InstallDir = /opt/applix/axdata/axshlib
|
||||
|
||||
<para>
|
||||
Playing around with MS Access will help you sort this out. Try using
|
||||
<literal>File->Get External Data</literal>.
|
||||
<menuchoice><guimenu>File</><guimenuitem>Get External Data</></menuchoice>.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
|
||||
@ -1,8 +1,11 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.4 2001/09/13 15:55:23 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.5 2001/11/12 19:19:39 petere Exp $ -->
|
||||
|
||||
<chapter id="plpython">
|
||||
<title>PL/Python - Python Procedural Language</title>
|
||||
|
||||
<indexterm zone="plpython"><primary>PL/Python</></>
|
||||
<indexterm zone="plpython"><primary>Python</></>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
This chapter is not fully developed yet.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.17 2001/09/13 15:55:23 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.18 2001/11/12 19:19:39 petere Exp $ -->
|
||||
|
||||
<Chapter Id="rules">
|
||||
<Title>The <ProductName>Postgres</ProductName> Rule System</Title>
|
||||
<Title>The Rule System</Title>
|
||||
|
||||
<indexterm zone="rules">
|
||||
<primary>rules</primary>
|
||||
@ -20,7 +20,7 @@
|
||||
them. Some of these points and
|
||||
the theoretical foundations of the <ProductName>Postgres</ProductName>
|
||||
rule system can be found in
|
||||
[<XRef LinkEnd="STON90b" EndTerm="STON90b">].
|
||||
<XRef LinkEnd="STON90b">.
|
||||
</Para>
|
||||
|
||||
<Para>
|
||||
@ -38,9 +38,9 @@
|
||||
is very powerful, and can be used for many things such
|
||||
as query language procedures, views, and versions. The
|
||||
power of this rule system is discussed in
|
||||
[<XRef LinkEnd="ONG90" EndTerm="ONG90">]
|
||||
<XRef LinkEnd="ONG90">
|
||||
as well as
|
||||
[<XRef LinkEnd="STON90b" EndTerm="STON90b">].
|
||||
<XRef LinkEnd="STON90b">.
|
||||
</para>
|
||||
<Sect1 id="querytree">
|
||||
<Title>What is a Query Tree?</Title>
|
||||
@ -110,6 +110,7 @@
|
||||
<Term>
|
||||
the range table
|
||||
</Term>
|
||||
<indexterm><primary>range table</></>
|
||||
<ListItem>
|
||||
<Para>
|
||||
The range table is a list of relations that are used in the query.
|
||||
@ -264,6 +265,7 @@
|
||||
|
||||
<Sect1 id="rules-views">
|
||||
<Title>Views and the Rule System</Title>
|
||||
<indexterm zone="rules-views"><primary>rules</><secondary>and views</></>
|
||||
|
||||
<Sect2>
|
||||
<Title>Implementation of Views in <ProductName>Postgres</ProductName></Title>
|
||||
@ -831,8 +833,9 @@
|
||||
</Sect3>
|
||||
</Sect2>
|
||||
|
||||
<Sect2>
|
||||
<Sect2 id="rules-views-update">
|
||||
<Title>What about updating a view?</Title>
|
||||
<indexterm zone="rules-views-update"><primary>views</><secondary>updating</></>
|
||||
|
||||
<Para>
|
||||
What happens if a view is named as the target relation for an INSERT,
|
||||
@ -1688,15 +1691,15 @@ Merge Join
|
||||
I think there are only a few situations out in the real
|
||||
world, where such a construct is necessary. But
|
||||
it makes me feel comfortable that it works.
|
||||
</Para>
|
||||
|
||||
<Note>
|
||||
<Title>The truth is</Title>
|
||||
<formalpara>
|
||||
<Title>The truth is:</Title>
|
||||
<Para>
|
||||
Doing this I found one more bug while writing this document.
|
||||
But after fixing that I was a little amazed that it works at all.
|
||||
</Para>
|
||||
</Note>
|
||||
</Para>
|
||||
</formalpara>
|
||||
</Sect2>
|
||||
|
||||
</Sect1>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.93 2001/11/08 23:39:22 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.94 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
@ -119,6 +119,7 @@ postgres> <userinput>initdb -D /usr/local/pgsql/data</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>LC_COLLATE</></>
|
||||
One surprise you might encounter while running <command>initdb</command> is
|
||||
a notice similar to this one:
|
||||
<screen>
|
||||
@ -238,6 +239,7 @@ su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
|
||||
For <productname>FreeBSD</productname>, take a look at the file
|
||||
<filename>contrib/start-scripts/freebsd</filename> in the
|
||||
<productname>PostgreSQL</productname> source distribution.
|
||||
<indexterm><primary>FreeBSD</></>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -245,6 +247,7 @@ su -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog' postgres
|
||||
<para>
|
||||
On <productname>OpenBSD</productname>, add the following lines
|
||||
to the file <filename>/etc/rc.local</filename>:
|
||||
<indexterm><primary>OpenBSD</></>
|
||||
<programlisting>
|
||||
if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postmaster ]; then
|
||||
su - -c '/usr/local/pgsql/bin/pg_ctl start -l /var/postgresql/log -s' postgres
|
||||
@ -257,6 +260,7 @@ fi
|
||||
<listitem>
|
||||
<para>
|
||||
On <productname>Linux</productname> systems either add
|
||||
<indexterm><primary>Linux</></>
|
||||
<programlisting>
|
||||
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
|
||||
</programlisting>
|
||||
@ -274,6 +278,7 @@ fi
|
||||
<productname>Linux</productname> start scripts, depending on
|
||||
preference, as an example and place the file at
|
||||
<filename>/usr/local/etc/rc.d/postgresql</filename>.
|
||||
<indexterm><primary>NetBSD</></>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -282,6 +287,7 @@ fi
|
||||
On <productname>Solaris</productname>, create a file called
|
||||
<filename>/etc/init.d/postgresql</filename> to contain the following
|
||||
single line:
|
||||
<indexterm><primary>Solaris</></>
|
||||
<programlisting>
|
||||
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
|
||||
</programlisting>
|
||||
@ -1013,6 +1019,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><varname>AUSTRALIAN_TIMEZONES</varname> (<type>bool</type>)</term>
|
||||
<indexterm><primary>Australian time zones</></>
|
||||
<listitem>
|
||||
<para>
|
||||
If set to true, <literal>CST</literal>, <literal>EST</literal>,
|
||||
@ -1025,6 +1032,7 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>AUTHENTICATION_TIMEOUT</varname> (<type>integer</type>)</term>
|
||||
<indexterm><primary>timeout</><secondary>authentication</></indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
Maximum time to complete client authentication, in seconds.
|
||||
@ -1042,6 +1050,10 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
<primary>deadlock</primary>
|
||||
<secondary>timeout</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>timeout</primary>
|
||||
<secondary>deadlock</secondary>
|
||||
</indexterm>
|
||||
|
||||
<term><varname>DEADLOCK_TIMEOUT</varname> (<type>integer</type>)</term>
|
||||
<listitem>
|
||||
@ -1091,6 +1103,8 @@ env PGOPTIONS='-c geqo=off' psql
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>DYNAMIC_LIBRARY_PATH</varname> (<type>string</type>)</term>
|
||||
<indexterm><primary>dynamic_library_path</></>
|
||||
<indexterm><primary>dynamic loading</></>
|
||||
<listitem>
|
||||
<para>
|
||||
If a dynamically loadable module needs to be opened and the
|
||||
@ -1298,6 +1312,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>PORT</varname> (<type>integer</type>)</term>
|
||||
<indexterm><primary>port</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The TCP port the server listens on; 5432 by default. This
|
||||
@ -1351,6 +1366,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>SQL_INHERITANCE</varname> (<type>bool</type>)</term>
|
||||
<indexterm><primary>inheritance</></>
|
||||
<listitem>
|
||||
<para>
|
||||
This controls the inheritance semantics, in particular whether
|
||||
@ -1395,6 +1411,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>TRANSFORM_NULL_EQUALS</varname> (<type>boolean</type>)</term>
|
||||
<indexterm><primary>IS NULL</></>
|
||||
<listitem>
|
||||
<para>
|
||||
When turned on, expressions of the form
|
||||
@ -1955,6 +1972,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">BSD/OS</></term>
|
||||
<indexterm><primary>BSD/OS</></>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Shared Memory</>
|
||||
@ -2020,6 +2038,9 @@ options "SEMMNU=120"
|
||||
<term><systemitem class="osname">FreeBSD</></term>
|
||||
<term><systemitem class="osname">NetBSD</></term>
|
||||
<term><systemitem class="osname">OpenBSD</></term>
|
||||
<indexterm><primary>FreeBSD</></>
|
||||
<indexterm><primary>NetBSD</></>
|
||||
<indexterm><primary>OpenBSD</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The options <varname>SYSVSHM</> and <varname>SYSVSEM</> need
|
||||
@ -2048,6 +2069,7 @@ options SEMMAP=256
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">HP-UX</></term>
|
||||
<indexterm><primary>HP-UX</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The default settings tend to suffice for normal installations.
|
||||
@ -2068,6 +2090,7 @@ options SEMMAP=256
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">Linux</></term>
|
||||
<indexterm><primary>Linux</></>
|
||||
<listitem>
|
||||
<para>
|
||||
The default shared memory limit (both
|
||||
@ -2110,6 +2133,7 @@ kernel.shmmax = 134217728
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">SCO OpenServer</></term>
|
||||
<indexterm><primary>SCO OpenServer</></>
|
||||
<listitem>
|
||||
<para>
|
||||
In the default configuration, only 512 kB of shared memory per
|
||||
@ -2137,6 +2161,7 @@ kernel.shmmax = 134217728
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">Solaris</></term>
|
||||
<indexterm><primary>Solaris</></>
|
||||
<listitem>
|
||||
<para>
|
||||
At least in version 2.6, the maximum size of a shared memory
|
||||
@ -2169,6 +2194,7 @@ set semsys:seminfo_semmsl=32
|
||||
|
||||
<varlistentry>
|
||||
<term><systemitem class="osname">UnixWare</></term>
|
||||
<indexterm><primary>Unixware</></>
|
||||
<listitem>
|
||||
<para>
|
||||
On <productname>UnixWare</> 7, the maximum size for shared
|
||||
|
||||
@ -1,10 +1,12 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.41 2001/11/01 04:07:29 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.42 2001/11/12 19:19:39 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
<title id="xfunc-title">Extending <acronym>SQL</acronym>: Functions</title>
|
||||
|
||||
<indexterm zone="xfunc"><primary>function</></>
|
||||
|
||||
<sect1 id="xfunc-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
@ -70,6 +72,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.41 2001/11/01 04:07:29 tgl E
|
||||
<sect1 id="xfunc-sql">
|
||||
<title>Query Language (<acronym>SQL</acronym>) Functions</title>
|
||||
|
||||
<indexterm zone="xfunc-sql"><primary>function</><secondary>SQL</></>
|
||||
|
||||
<para>
|
||||
SQL functions execute an arbitrary list of SQL statements, returning
|
||||
the result of the last query in the list, which must be a
|
||||
@ -83,6 +87,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.41 2001/11/01 04:07:29 tgl E
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<indexterm><primary>SETOF</><seealso>function</></>
|
||||
Alternatively, an SQL function may be declared to return a set,
|
||||
by specifying the function's return type
|
||||
as <literal>SETOF</literal> <replaceable>sometype</>. In this case
|
||||
@ -475,6 +480,8 @@ SELECT name, listchildren(name) FROM nodes;
|
||||
<sect1 id="xfunc-internal">
|
||||
<title>Internal Functions</title>
|
||||
|
||||
<indexterm zone="xfunc-internal"><primary>function</><secondary>internal</></>
|
||||
|
||||
<para>
|
||||
Internal functions are functions written in C that have been statically
|
||||
linked into the <productname>PostgreSQL</productname> server.
|
||||
@ -569,7 +576,7 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
<para>
|
||||
If the name starts with the string <literal>$libdir</literal>,
|
||||
that part is replaced by the PostgreSQL package library directory
|
||||
name, which is determined at build time.
|
||||
name, which is determined at build time.<indexterm><primary>$libdir</></>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -577,7 +584,7 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
<para>
|
||||
If the name does not contain a directory part, the file is
|
||||
searched for in the path specified by the configuration variable
|
||||
<varname>dynamic_library_path</varname>.
|
||||
<varname>dynamic_library_path</varname>.<indexterm><primary>dynamic_library_path</></>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1406,7 +1413,7 @@ LANGUAGE C;
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Use <literal>pg_config --includedir-server</literal> to find
|
||||
Use <literal>pg_config --includedir-server</literal><indexterm><primary>pg_config</></> to find
|
||||
out where the PostgreSQL server header files are installed on
|
||||
your system (or the system that your users will be running
|
||||
on). This option is new with PostgreSQL 7.2. For PostgreSQL
|
||||
@ -1492,6 +1499,8 @@ LANGUAGE C;
|
||||
<sect1 id="xfunc-overload">
|
||||
<title>Function Overloading</title>
|
||||
|
||||
<indexterm zone="xfunc-overload"><primary>overloading</></>
|
||||
|
||||
<para>
|
||||
More than one function may be defined with the same SQL name, so long
|
||||
as the arguments they take are different. In other words,
|
||||
|
||||
Loading…
Reference in New Issue
Block a user