Spellchecking and such
This commit is contained in:
parent
033cb9d30b
commit
0f763503ff
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.90 2006/10/12 19:38:08 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.91 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -977,7 +977,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
|
||||
If recovery fails for an external reason, such as a system crash or
|
||||
the WAL archive has become inaccessible, then the recovery can be
|
||||
simply restarted and it will restart almost from where it failed.
|
||||
Restartable recovery works by writing a restartpoint record to the control
|
||||
Restartable recovery works by writing a restart-point record to the control
|
||||
file at the first safely usable checkpoint record found after
|
||||
<varname>checkpoint_timeout</> seconds.
|
||||
</para>
|
||||
@ -1188,7 +1188,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
|
||||
|
||||
<para>
|
||||
If we take a backup of the server files whilst a recovery is in progress,
|
||||
we will be able to restart the recovery from the last restartpoint.
|
||||
we will be able to restart the recovery from the last restart point.
|
||||
That backup now has many of the changes from previous WAL archive files,
|
||||
so this version is now an updated version of the original base backup.
|
||||
If we need to recover, it will be faster to recover from the
|
||||
@ -1595,7 +1595,7 @@ if (!triggered)
|
||||
|
||||
<para>
|
||||
An external program can call <function>pg_xlogfile_name_offset()</>
|
||||
to find out the filename and the exact byte offset within it of
|
||||
to find out the file name and the exact byte offset within it of
|
||||
the latest WAL pointer. If the external program regularly polls
|
||||
the server it can find out how far forward the pointer has
|
||||
moved. It can then access the WAL file directly and copy those
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.134 2006/09/22 23:20:13 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.135 2006/10/23 18:10:30 petere Exp $ -->
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
-->
|
||||
@ -405,7 +405,7 @@
|
||||
<entry><structfield>amclusterable</structfield></entry>
|
||||
<entry><type>bool</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Can an index of this type be CLUSTERed on?</entry>
|
||||
<entry>Can an index of this type be clustered on?</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -496,7 +496,7 @@
|
||||
<entry><structfield>amoptions</structfield></entry>
|
||||
<entry><type>regproc</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
|
||||
<entry>Function to parse and validate reloptions for an index</entry>
|
||||
<entry>Function to parse and validate <structfield>reloptions</> for an index</entry>
|
||||
</row>
|
||||
|
||||
</tbody>
|
||||
@ -1209,7 +1209,7 @@
|
||||
<entry><structfield>vac_scale_factor</structfield></entry>
|
||||
<entry><type>float4</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Multiplier for reltuples to add to
|
||||
<entry>Multiplier for <structfield>reltuples</> to add to
|
||||
<structfield>vac_base_thresh</></entry>
|
||||
</row>
|
||||
|
||||
@ -1224,7 +1224,7 @@
|
||||
<entry><structfield>anl_scale_factor</structfield></entry>
|
||||
<entry><type>float4</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Multiplier for reltuples to add to
|
||||
<entry>Multiplier for <structfield>reltuples</> to add to
|
||||
<structfield>anl_base_thresh</></entry>
|
||||
</row>
|
||||
|
||||
@ -2043,7 +2043,7 @@
|
||||
operation. All rows inserted or deleted by transaction IDs before this one
|
||||
have been marked as known good or deleted. This
|
||||
is used to determine when commit-log space can be recycled.
|
||||
If InvalidTransactionId, then the minimum is unknown and can be
|
||||
If <symbol>InvalidTransactionId</symbol>, then the minimum is unknown and can be
|
||||
determined by scanning <structname>pg_class</>.<structfield>relvacuumxid</>.
|
||||
</entry>
|
||||
</row>
|
||||
@ -2058,7 +2058,7 @@
|
||||
relabeled with a permanent (<quote>frozen</>) transaction ID in this
|
||||
database. This is useful to check whether a database must be
|
||||
vacuumed soon to avoid transaction ID wrap-around problems.
|
||||
If InvalidTransactionId, then the minimum is unknown and can be
|
||||
If <symbol>InvalidTransactionId</symbol>, then the minimum is unknown and can be
|
||||
determined by scanning <structname>pg_class</>.<structfield>relminxid</>.
|
||||
</entry>
|
||||
</row>
|
||||
@ -3353,7 +3353,7 @@
|
||||
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
An array with the data types of the function arguments. This includes
|
||||
only input arguments (including INOUT arguments), and thus represents
|
||||
only input arguments (including <literal>INOUT</literal> arguments), and thus represents
|
||||
the call signature of the function.
|
||||
</entry>
|
||||
</row>
|
||||
@ -3364,7 +3364,7 @@
|
||||
<entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
An array with the data types of the function arguments. This includes
|
||||
all arguments (including OUT and INOUT arguments); however, if all the
|
||||
all arguments (including <literal>OUT</literal> and <literal>INOUT</literal> arguments); however, if all the
|
||||
arguments are IN arguments, this field will be null.
|
||||
Note that subscripting is 1-based, whereas for historical reasons
|
||||
<structfield>proargtypes</> is subscripted from 0.
|
||||
@ -3377,10 +3377,10 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
An array with the modes of the function arguments, encoded as
|
||||
<literal>i</literal> for IN arguments,
|
||||
<literal>o</literal> for OUT arguments,
|
||||
<literal>b</literal> for INOUT arguments.
|
||||
If all the arguments are IN arguments, this field will be null.
|
||||
<literal>i</literal> for <literal>IN</> arguments,
|
||||
<literal>o</literal> for <literal>OUT</> arguments,
|
||||
<literal>b</literal> for <literal>INOUT</> arguments.
|
||||
If all the arguments are <literal>IN</literal> arguments, this field will be null.
|
||||
Note that subscripts correspond to positions of
|
||||
<structfield>proallargtypes</> not <structfield>proargtypes</>.
|
||||
</entry>
|
||||
@ -5031,7 +5031,7 @@
|
||||
|
||||
<para>
|
||||
Advisory locks can be acquired on keys consisting of either a single
|
||||
bigint value or two integer values. A bigint key is displayed with its
|
||||
<type>bigint</type> value or two integer values. A <type>bigint</type> key is displayed with its
|
||||
high-order half in the <structfield>classid</> column, its low-order half
|
||||
in the <structfield>objid</> column, and <structfield>objsubid</> equal
|
||||
to 1. Integer keys are displayed with the first key in the
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.93 2006/09/16 00:30:11 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.94 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
<title>Client Authentication</title>
|
||||
@ -947,9 +947,9 @@ ldap://ldap.example.net/dc=example,dc=net;EXAMPLE\
|
||||
</para>
|
||||
<para>
|
||||
The server will bind to the distinguished name specified as
|
||||
<replaceable>base dn</> using the username supplied by the client.
|
||||
<replaceable>base dn</> using the user name supplied by the client.
|
||||
If <replaceable>prefix</> and <replaceable>suffix</> is
|
||||
specified, it will be prepended and appended to the username
|
||||
specified, it will be prepended and appended to the user name
|
||||
before the bind. Typically, the prefix parameter is used to specify
|
||||
<replaceable>cn=</>, or <replaceable>DOMAIN\</> in an Active
|
||||
Directory environment.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.91 2006/10/19 22:55:25 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.92 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<chapter Id="runtime-config">
|
||||
<title>Server Configuration</title>
|
||||
@ -75,7 +75,7 @@ shared_buffers = 128MB
|
||||
<programlisting>
|
||||
include 'filename'
|
||||
</programlisting>
|
||||
If the filename is not an absolute path, it is taken as relative to
|
||||
If the file name is not an absolute path, it is taken as relative to
|
||||
the directory containing the referencing configuration file.
|
||||
Inclusions can be nested.
|
||||
</para>
|
||||
@ -206,7 +206,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<para>
|
||||
Specifies the main server configuration file
|
||||
(customarily called <filename>postgresql.conf</>).
|
||||
This parameter can only be set on the postgres command line.
|
||||
This parameter can only be set on the <command>postgres</command> command line.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -265,7 +265,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
|
||||
<para>
|
||||
If you wish to keep the configuration files elsewhere than the
|
||||
data directory, the postgres <option>-D</option>
|
||||
data directory, the <command>postgres</command> <option>-D</option>
|
||||
command-line option or <envar>PGDATA</envar> environment variable
|
||||
must point to the directory containing the configuration files,
|
||||
and the <varname>data_directory</> parameter must be set in
|
||||
@ -1422,8 +1422,8 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
or power failure. The risks are similar to turning off
|
||||
<varname>fsync</>, though smaller. It may be safe to turn off
|
||||
this parameter if you have hardware (such as a battery-backed disk
|
||||
controller) or filesystem software (e.g., Reiser4) that reduces
|
||||
the risk of partial page writes to an acceptably low level.
|
||||
controller) or file-system software that reduces
|
||||
the risk of partial page writes to an acceptably low level (e.g., ReiserFS 4).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -3901,10 +3901,10 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
<listitem>
|
||||
<para>
|
||||
This controls whether the array input parser recognizes
|
||||
unquoted <literal>NULL</> as specifying a NULL array element.
|
||||
unquoted <literal>NULL</> as specifying a null array element.
|
||||
By default, this is <literal>on</>, allowing array values containing
|
||||
NULLs to be entered. However, <productname>PostgreSQL</> versions
|
||||
before 8.2 did not support NULLs in arrays, and therefore would
|
||||
null values to be entered. However, <productname>PostgreSQL</> versions
|
||||
before 8.2 did not support null values in arrays, and therefore would
|
||||
treat <literal>NULL</> as specifying a normal array element with
|
||||
the string value <quote>NULL</>. For backwards compatibility with
|
||||
applications that require the old behavior, this variable can be
|
||||
@ -3912,7 +3912,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that it is possible to create array values containing NULLs
|
||||
Note that it is possible to create array values containing null values
|
||||
even when this variable is <literal>off</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.37 2006/03/10 19:10:47 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.38 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<appendix id="cvs">
|
||||
<appendixinfo>
|
||||
@ -91,7 +91,7 @@ cvs -z3 -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co -P pgsql
|
||||
<para>
|
||||
If you have a fast link to the Internet, you may not need
|
||||
<option>-z3</option>, which instructs
|
||||
<productname>CVS</productname> to use gzip compression for transferred data. But
|
||||
<productname>CVS</productname> to use <command>gzip</command> compression for transferred data. But
|
||||
on a modem-speed link, it's a very substantial win.
|
||||
</para>
|
||||
</note>
|
||||
@ -131,8 +131,8 @@ cvs -z3
|
||||
update -d -P
|
||||
</programlisting>
|
||||
|
||||
This supplies the <option>-z3</option> option to all cvs commands, and the
|
||||
<option>-d</option> and <option>-P</option> options to cvs update. Then you just have
|
||||
This supplies the <option>-z3</option> option to all <command>cvs</> commands, and the
|
||||
<option>-d</option> and <option>-P</option> options to <command>cvs update</>. Then you just have
|
||||
to say
|
||||
<programlisting>
|
||||
cvs update
|
||||
@ -206,7 +206,7 @@ cvs checkout -r REL6_4 tc
|
||||
|
||||
<para>
|
||||
When you tag more than one file with the same tag you can think
|
||||
about the tag as <quote>a curve drawn through a matrix of filename vs.
|
||||
about the tag as <quote>a curve drawn through a matrix of file name vs.
|
||||
revision number</quote>. Say we have 5 files with the following revisions:
|
||||
|
||||
<programlisting>
|
||||
@ -304,7 +304,7 @@ cvs commit
|
||||
A major advantage to using
|
||||
<productname>CVSup</productname> is that it can reliably
|
||||
replicate the <emphasis>entire</emphasis> CVS repository on your local system,
|
||||
allowing fast local access to cvs operations such as <option>log</option>
|
||||
allowing fast local access to <command>cvs</> operations such as <option>log</option>
|
||||
and <option>diff</option>. Other advantages include fast synchronization to
|
||||
the <productname>PostgreSQL</productname> server due to an efficient
|
||||
streaming transfer protocol which only sends the changes since the last update.
|
||||
@ -445,7 +445,7 @@ CVSROOT/loginfo*
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following is a suggested <productname>CVSup</productname> config file from
|
||||
The following is a suggested <productname>CVSup</productname> configuration file from
|
||||
the <productname>PostgreSQL</>
|
||||
<ulink url="ftp://ftp.postgresql.org/pub/CVSup/README.cvsup">
|
||||
ftp site</ulink>
|
||||
@ -570,7 +570,7 @@ mv cvsup.1 ../doc/man/man1/
|
||||
<step>
|
||||
<para>
|
||||
If there is a directory structure in the tar file, then unpack
|
||||
the tar file within /usr/local/src and move the binaries into
|
||||
the tar file within <filename>/usr/local/src</filename> and move the binaries into
|
||||
the appropriate location as above.
|
||||
</para>
|
||||
</step>
|
||||
@ -645,7 +645,7 @@ $ which cvsup
|
||||
|
||||
<step>
|
||||
<para>
|
||||
Install the Modula-3 rpms:
|
||||
Install the Modula-3 RPMs:
|
||||
|
||||
<programlisting>
|
||||
# rpm -Uvh pm3*.rpm
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.179 2006/10/18 16:43:13 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.180 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<chapter id="datatype">
|
||||
<title id="datatype-title">Data Types</title>
|
||||
@ -3362,7 +3362,7 @@ SELECT * FROM pg_attribute
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<acronym>XML</> (eXtensible Markup Language) support is not one
|
||||
<acronym>XML</> (Extensible Markup Language) support is not one
|
||||
capability, but a variety of features supported by a database
|
||||
system. These capabilities include storage, import/export,
|
||||
validation, indexing, efficiency of modification, searching,
|
||||
@ -3429,7 +3429,7 @@ SELECT * FROM pg_attribute
|
||||
indexes to index specific <acronym>XML</> fields. To index the
|
||||
full contents of <acronym>XML</> documents, the full-text indexing
|
||||
tool <filename>/contrib/tsearch2</> can be used. Of course,
|
||||
tsearch2 indexes have no <acronym>XML</> awareness so additional
|
||||
Tsearch2 indexes have no <acronym>XML</> awareness so additional
|
||||
<filename>/contrib/xml2</> checks should be added to queries.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3466,7 +3466,7 @@ SELECT * FROM pg_attribute
|
||||
<listitem>
|
||||
|
||||
<para>
|
||||
<filename>/contrib/xml2</> supports <acronym>XSLT</> (XML
|
||||
<filename>/contrib/xml2</> supports <acronym>XSLT</> (Extensible
|
||||
Stylesheet Language Transformation).
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.66 2006/10/22 03:03:40 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.67 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -2586,7 +2586,7 @@ UNION ALL SELECT * FROM measurement_y2006m01;
|
||||
|
||||
However, the need to
|
||||
recreate the view adds an extra step to adding and dropping
|
||||
individual partitions of the dataset.
|
||||
individual partitions of the data set.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -2778,7 +2778,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01';
|
||||
Constraint exclusion only works when the query's <literal>WHERE</>
|
||||
clause contains constants. A parameterized query will not be
|
||||
optimized, since the planner cannot know what partitions the
|
||||
parameter value might select at runtime. For the same reason,
|
||||
parameter value might select at run time. For the same reason,
|
||||
<quote>stable</> functions such as <function>CURRENT_DATE</function>
|
||||
must be avoided.
|
||||
</para>
|
||||
@ -2786,7 +2786,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01';
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Avoid cross-datatype comparisons in the <literal>CHECK</>
|
||||
Avoid cross-data type comparisons in the <literal>CHECK</>
|
||||
constraints, as the planner will currently fail to prove such
|
||||
conditions false. For example, the following constraint
|
||||
will work if <varname>x</varname> is an <type>integer</type>
|
||||
@ -2802,7 +2802,7 @@ CHECK ( x = 1::bigint )
|
||||
The problem is not limited to the <type>bigint</type> data type
|
||||
— it can occur whenever the default data type of the
|
||||
constant does not match the data type of the column to which it
|
||||
is being compared. Cross-datatype comparisons in the supplied
|
||||
is being compared. Cross-data type comparisons in the supplied
|
||||
queries are usually OK, just not in the <literal>CHECK</> conditions.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.58 2006/10/23 14:13:43 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.59 2006/10/23 18:10:30 petere Exp $ -->
|
||||
|
||||
<appendix id="docguide">
|
||||
<title>Documentation</title>
|
||||
@ -290,7 +290,7 @@ make install
|
||||
<envar>SGML_CATALOG_FILES</envar> to point to the file
|
||||
whenever you use <application>jade</application> later on.
|
||||
(This method is also an option if OpenJade is already
|
||||
installed and you want to install the rest of the toolchain
|
||||
installed and you want to install the rest of the tool chain
|
||||
locally.)
|
||||
</para>
|
||||
</step>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.76 2006/09/22 15:22:04 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.77 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="ecpg">
|
||||
<title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
|
||||
@ -472,7 +472,7 @@ EXEC SQL int i = 4;
|
||||
<para>
|
||||
As a host variable you can also use arrays, typedefs, structs and
|
||||
pointers. Moreover there are special types of host variables that exist
|
||||
only in ecpg.
|
||||
only in ECPG.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -539,9 +539,9 @@ EXEC SQL END DECLARE SECTION;
|
||||
<term>Special types of variables</term>
|
||||
<listitem>
|
||||
<para>
|
||||
ecpg contains some special types that help you to interact easily with
|
||||
ECPG contains some special types that help you to interact easily with
|
||||
data from the SQL server. For example it has implemented support for
|
||||
the varchar, numeric, date, timestamp and interval types.
|
||||
the <type>varchar</>, <type>numeric</>, <type>date</>, <type>timestamp</>, and <type>interval</> types.
|
||||
<xref linkend="ecpg-pgtypes"> contains basic functions to deal with
|
||||
those types, such that you do not need to send a query to the SQL
|
||||
server just for adding an interval to a timestamp for example.
|
||||
@ -835,7 +835,7 @@ numeric *PGTYPESnumeric_from_asc(char *str, char **endptr);
|
||||
<term><function>PGTYPESnumeric_to_asc</function></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns a pointer to a malloced string that contains the string
|
||||
Returns a pointer to a string allocated by <function>malloc</function> that contains the string
|
||||
representation of the numeric type <literal>num</literal>.
|
||||
<synopsis>
|
||||
char *PGTYPESnumeric_to_asc(numeric *num, int dscale);
|
||||
@ -1012,7 +1012,7 @@ int PGTYPESnumeric_to_double(numeric *nv, double *dp)
|
||||
</synopsis>
|
||||
The function converts the numeric value from the variable that
|
||||
<literal>nv</> points to into the double variable that <literal>dp</> points
|
||||
to. It retuns 0 on success and -1 if an error occurs, including
|
||||
to. It returns 0 on success and -1 if an error occurs, including
|
||||
overflow. On overflow, the global variable <literal>errno</> will be set
|
||||
to <literal>PGTYPES_NUM_OVERFLOW</> additionally.
|
||||
</para>
|
||||
@ -1029,7 +1029,7 @@ int PGTYPESnumeric_to_int(numeric *nv, int *ip);
|
||||
</synopsis>
|
||||
The function converts the numeric value from the variable that
|
||||
<literal>nv</> points to into the integer variable that <literal>ip</>
|
||||
points to. It retuns 0 on success and -1 if an error occurs, including
|
||||
points to. It returns 0 on success and -1 if an error occurs, including
|
||||
overflow. On overflow, the global variable <literal>errno</> will be set
|
||||
to <literal>PGTYPES_NUM_OVERFLOW</> additionally.
|
||||
</para>
|
||||
@ -1046,7 +1046,7 @@ int PGTYPESnumeric_to_long(numeric *nv, long *lp);
|
||||
</synopsis>
|
||||
The function converts the numeric value from the variable that
|
||||
<literal>nv</> points to into the long integer variable that
|
||||
<literal>lp</> points to. It retuns 0 on success and -1 if an error
|
||||
<literal>lp</> points to. It returns 0 on success and -1 if an error
|
||||
occurs, including overflow. On overflow, the global variable
|
||||
<literal>errno</> will be set to <literal>PGTYPES_NUM_OVERFLOW</>
|
||||
additionally.
|
||||
@ -1064,7 +1064,7 @@ int PGTYPESnumeric_to_decimal(numeric *src, decimal *dst);
|
||||
</synopsis>
|
||||
The function converts the numeric value from the variable that
|
||||
<literal>src</> points to into the decimal variable that
|
||||
<literal>dst</> points to. It retuns 0 on success and -1 if an error
|
||||
<literal>dst</> points to. It returns 0 on success and -1 if an error
|
||||
occurs, including overflow. On overflow, the global variable
|
||||
<literal>errno</> will be set to <literal>PGTYPES_NUM_OVERFLOW</>
|
||||
additionally.
|
||||
@ -1082,7 +1082,7 @@ int PGTYPESnumeric_from_decimal(decimal *src, numeric *dst);
|
||||
</synopsis>
|
||||
The function converts the decimal value from the variable that
|
||||
<literal>src</> points to into the numeric variable that
|
||||
<literal>dst</> points to. It retuns 0 on success and -1 if an error
|
||||
<literal>dst</> points to. It returns 0 on success and -1 if an error
|
||||
occurs. Since the decimal type is implemented as a limited version of
|
||||
the numeric type, overflow can not occur with this conversion.
|
||||
</para>
|
||||
@ -1607,7 +1607,7 @@ timestamp PGTYPEStimestamp_from_asc(char *str, char **endptr);
|
||||
specification. Note that timezones are not supported by ecpg. It can
|
||||
parse them but does not apply any calculation as the
|
||||
<productname>PostgreSQL</> server does for example. Timezone
|
||||
specificiers are silently discarded.
|
||||
specifiers are silently discarded.
|
||||
</para>
|
||||
<para>
|
||||
The following table contains a few examples for input strings:
|
||||
@ -2194,7 +2194,7 @@ int PGTYPESinterval_copy(interval *intvlsrc, interval *intvldest);
|
||||
type which can be created on the heap only, the decimal type can be
|
||||
created either on the stack or on the heap (by means of the functions
|
||||
PGTYPESdecimal_new() and PGTYPESdecimal_free(). There are a lot of other
|
||||
functions that deal with the decimal type in the Informix compatibility
|
||||
functions that deal with the decimal type in the <productname>Informix</productname> compatibility
|
||||
mode described in <xref linkend="ecpg-informix-compat">.
|
||||
</para>
|
||||
<para>
|
||||
@ -2375,11 +2375,11 @@ void PGTYPESdecimal_free(decimal *var);
|
||||
</sect1>
|
||||
|
||||
<sect1 id="ecpg-informix-compat">
|
||||
<title>Informix compatibility mode</title>
|
||||
<title><productname>Informix</productname> compatibility mode</title>
|
||||
<para>
|
||||
ecpg can be run in a so-called <firstterm>Informix compatibility mode</>. If
|
||||
this mode is active, it tries to behave as if it were the Informix
|
||||
precompiler for Informix E/SQL. Generally spoken this will allow you to use
|
||||
this mode is active, it tries to behave as if it were the <productname>Informix</productname>
|
||||
precompiler for <productname>Informix</productname> E/SQL. Generally spoken this will allow you to use
|
||||
the dollar sign instead of the <literal>EXEC SQL</> primitive to introduce
|
||||
embedded SQL commands.
|
||||
<programlisting>
|
||||
@ -2398,19 +2398,19 @@ void PGTYPESdecimal_free(decimal *var);
|
||||
against <literal>libcompat</> that is shipped with ecpg.
|
||||
</para>
|
||||
<para>
|
||||
Besides the previously explained syntactic sugar, the Informix compatibility
|
||||
Besides the previously explained syntactic sugar, the <productname>Informix</productname> compatibility
|
||||
mode ports some functions for input, output and transformation of data as
|
||||
well as embedded SQL statements known from E/SQL to ecpg.
|
||||
</para>
|
||||
<para>
|
||||
Informix compatibility mode is closely connected to the pgtypeslib library
|
||||
<productname>Informix</productname> compatibility mode is closely connected to the pgtypeslib library
|
||||
of ecpg. pgtypeslib maps SQL data types to data types within the C host
|
||||
program and most of the additional functions of the Informix compatibility
|
||||
program and most of the additional functions of the <productname>Informix</productname> compatibility
|
||||
mode allow you to operate on those C host program types. Note however that
|
||||
the extent of the compatibility is limited. It does not try to copy Informix
|
||||
the extent of the compatibility is limited. It does not try to copy <productname>Informix</productname>
|
||||
behaviour; it allows you to do more or less the same operations and gives
|
||||
you functions that have the same name and the same basic behavior but it is
|
||||
no drop-in replacement if you are using Informix at the moment. Moreover,
|
||||
no drop-in replacement if you are using <productname>Informix</productname> at the moment. Moreover,
|
||||
some of the data types are different. For example,
|
||||
<productname>PostgreSQL's</productname> datetime and interval types do not
|
||||
know about ranges like for example <literal>YEAR TO MINUTE</> so you won't
|
||||
@ -2540,7 +2540,7 @@ int deccvasc(char *cp, int len, decimal *np);
|
||||
<literal>ECPG_INFORMIX_NUM_UNDERFLOW</> is returned. If the ASCII
|
||||
representation could not be parsed,
|
||||
<literal>ECPG_INFORMIX_BAD_NUMERIC</> is returned or
|
||||
<literal>ECPG_INFORMIX_BAD_EXPONENT</> if this problem ocurred while
|
||||
<literal>ECPG_INFORMIX_BAD_EXPONENT</> if this problem occurred while
|
||||
parsing the exponent.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2741,8 +2741,8 @@ int dectoint(decimal *np, int *ip);
|
||||
is returned.
|
||||
</para>
|
||||
<para>
|
||||
Note that the ecpg implementation differs from the Informix
|
||||
implementation. Informix limits an integer to the range from -32767 to
|
||||
Note that the ecpg implementation differs from the <productname>Informix</productname>
|
||||
implementation. <productname>Informix</productname> limits an integer to the range from -32767 to
|
||||
32767, while the limits in the ecpg implementation depend on the
|
||||
architecture (<literal>-INT_MAX .. INT_MAX</>).
|
||||
</para>
|
||||
@ -2767,8 +2767,8 @@ int dectolong(decimal *np, long *lngp);
|
||||
is returned.
|
||||
</para>
|
||||
<para>
|
||||
Note that the ecpg implementation differs from the Informix
|
||||
implementation. Informix limits a long integer to the range from
|
||||
Note that the ecpg implementation differs from the <productname>Informix</productname>
|
||||
implementation. <productname>Informix</productname> limits a long integer to the range from
|
||||
-2,147,483,647 to 2,147,483,647, while the limits in the ecpg
|
||||
implementation depend on the architecture (<literal>-LONG_MAX ..
|
||||
LONG_MAX</>).
|
||||
@ -2795,8 +2795,8 @@ int rdatestr(date d, char *str);
|
||||
error.
|
||||
</para>
|
||||
<para>
|
||||
Note that ecpg's implementation differs from the Informix
|
||||
implementation. In Informix the format can be influenced by setting
|
||||
Note that ecpg's implementation differs from the <productname>Informix</productname>
|
||||
implementation. In <productname>Informix</productname> the format can be influenced by setting
|
||||
environment variables. In ecpg however, you cannot change the output
|
||||
format.
|
||||
</para>
|
||||
@ -2814,7 +2814,7 @@ int rstrdate(char *str, date *d);
|
||||
The function receives the textual representation of the date to convert
|
||||
(<literal>str</>) and a pointer to a variable of type date
|
||||
(<literal>d</>). This function does not allow you to specify a format
|
||||
mask. It uses the default format mask of Informix which is
|
||||
mask. It uses the default format mask of <productname>Informix</productname> which is
|
||||
<literal>mm/dd/yyyy</>. Internally, this function is implemented by
|
||||
means of <function>rdefmtdate</>. Therefore, <function>rstrdate</> is
|
||||
not faster and if you have the choice you should opt for
|
||||
@ -3167,9 +3167,9 @@ int dttofmtasc(timestamp *ts, char *output, int str_len, char *fmtstr);
|
||||
error occurred.
|
||||
</para>
|
||||
<para>
|
||||
Internally this function uses the <xref
|
||||
Internally, this function uses the <xref
|
||||
linkend="PGTYPEStimestampfmtasc"> function. See the reference there for
|
||||
informations on what format mask specifiers can be used.
|
||||
information on what format mask specifiers can be used.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3396,52 +3396,52 @@ int rsetnull(int t, char *ptr);
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CCHARTYPE</literal> - For a variable of type char or char*
|
||||
<literal>CCHARTYPE</literal> - For a variable of type <type>char</type> or <type>char*</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CSHORTTYPE</literal> - For a variable of type short int
|
||||
<literal>CSHORTTYPE</literal> - For a variable of type <type>short int</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CINTTYPE</literal> - For a variable of type int
|
||||
<literal>CINTTYPE</literal> - For a variable of type <type>int</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CBOOLTYPE</literal> - For a variable of type boolean
|
||||
<literal>CBOOLTYPE</literal> - For a variable of type <type>boolean</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CFLOATTYPE</literal> - For a variable of type float
|
||||
<literal>CFLOATTYPE</literal> - For a variable of type <type>float</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CLONGTYPE</literal> - For a variable of type long
|
||||
<literal>CLONGTYPE</literal> - For a variable of type <type>long</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CDOUBLETYPE</literal> - For a variable of type double
|
||||
<literal>CDOUBLETYPE</literal> - For a variable of type <type>double</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CDECIMALTYPE</literal> - For a variable of type decimal
|
||||
<literal>CDECIMALTYPE</literal> - For a variable of type <type>decimal</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CDATETYPE</literal> - For a variable of type date
|
||||
<literal>CDATETYPE</literal> - For a variable of type <type>date</type>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<literal>CDTIMETYPE</literal> - For a variable of type timestamp
|
||||
<literal>CDTIMETYPE</literal> - For a variable of type <type>timestamp</type>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -3508,7 +3508,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if an overflow occurred in a
|
||||
calculation. Internally it is defined to -1200 (the Informix
|
||||
calculation. Internally it is defined to -1200 (the <productname>Informix</productname>
|
||||
definition).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3519,7 +3519,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if an underflow occurred in a calculation.
|
||||
Internally it is defined to -1201 (the Informix definition).
|
||||
Internally it is defined to -1201 (the <productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3529,7 +3529,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if an attempt to divide by zero is
|
||||
observed. Internally it is defined to -1202 (the Informix definition).
|
||||
observed. Internally it is defined to -1202 (the <productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3539,7 +3539,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if a bad value for a year was found while
|
||||
parsing a date. Internally it is defined to -1204 (the Informix
|
||||
parsing a date. Internally it is defined to -1204 (the <productname>Informix</productname>
|
||||
definition).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3550,7 +3550,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if a bad value for a month was found while
|
||||
parsing a date. Internally it is defined to -1205 (the Informix
|
||||
parsing a date. Internally it is defined to -1205 (the <productname>Informix</productname>
|
||||
definition).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3561,7 +3561,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if a bad value for a day was found while
|
||||
parsing a date. Internally it is defined to -1206 (the Informix
|
||||
parsing a date. Internally it is defined to -1206 (the <productname>Informix</productname>
|
||||
definition).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3573,7 +3573,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<para>
|
||||
Functions return this value if a parsing routine needs a short date
|
||||
representation but did not get the date string in the right length.
|
||||
Internally it is defined to -1209 (the Informix definition).
|
||||
Internally it is defined to -1209 (the <productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3583,7 +3583,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if Internally it is defined to -1210 (the
|
||||
Informix definition).
|
||||
<productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3593,7 +3593,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if Internally it is defined to -1211 (the
|
||||
Informix definition).
|
||||
<productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3604,7 +3604,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<para>
|
||||
Functions return this value if a parsing routine was supposed to get a
|
||||
format mask (like <literal>mmddyy</>) but not all fields were listed
|
||||
correctly. Internally it is defined to -1212 (the Informix definition).
|
||||
correctly. Internally it is defined to -1212 (the <productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3617,7 +3617,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
the textual representation for a numeric value because it contains
|
||||
errors or if a routine cannot complete a calculation involving numeric
|
||||
variables because at least one of the numeric variables is invalid.
|
||||
Internally it is defined to -1213 (the Informix definition).
|
||||
Internally it is defined to -1213 (the <productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3627,7 +3627,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if Internally it is defined to -1216 (the
|
||||
Informix definition).
|
||||
<productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3637,7 +3637,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if Internally it is defined to -1218 (the
|
||||
Informix definition).
|
||||
<productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3647,7 +3647,7 @@ risnull(CINTTYPE, (char *) &i);
|
||||
<listitem>
|
||||
<para>
|
||||
Functions return this value if Internally it is defined to -1264 (the
|
||||
Informix definition).
|
||||
<productname>Informix</productname> definition).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.343 2006/10/01 18:54:31 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.344 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="functions">
|
||||
<title>Functions and Operators</title>
|
||||
@ -7686,7 +7686,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
|
||||
<para>
|
||||
Array comparisons compare the array contents element-by-element,
|
||||
using the default btree comparison function for the element data type.
|
||||
using the default B-Tree comparison function for the element data type.
|
||||
In multidimensional arrays the elements are visited in row-major order
|
||||
(last subscript varies most rapidly).
|
||||
If the contents of two arrays are equal but the dimensionality is
|
||||
@ -9003,8 +9003,8 @@ AND
|
||||
<literal>></> or
|
||||
<literal>>=</>,
|
||||
or has semantics similar to one of these. (To be specific, an operator
|
||||
can be a row comparison operator if it is a member of a btree operator
|
||||
class, or is the negator of the <literal>=</> member of a btree operator
|
||||
can be a row comparison operator if it is a member of a B-Tree operator
|
||||
class, or is the negator of the <literal>=</> member of a B-Tree operator
|
||||
class.)
|
||||
</para>
|
||||
|
||||
@ -10251,35 +10251,35 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
<literal><function>pg_switch_xlog</function>()</literal>
|
||||
</entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Force switch to a new xlog file</entry>
|
||||
<entry>Force switch to a new transaction log file</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_current_xlog_location</function>()</literal>
|
||||
</entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Get current xlog write location</entry>
|
||||
<entry>Get current transaction log write location</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_current_xlog_insert_location</function>()</literal>
|
||||
</entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Get current xlog insert location</entry>
|
||||
<entry>Get current transaction log insert location</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_xlogfile_name_offset</function>(<parameter>location</> <type>text</>)</literal>
|
||||
</entry>
|
||||
<entry><type>text</>, <type>integer</></entry>
|
||||
<entry>Convert xlog location string to filename and decimal byte offset within file</entry>
|
||||
<entry>Convert transaction log location string to file name and decimal byte offset within file</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>
|
||||
<literal><function>pg_xlogfile_name</function>(<parameter>location</> <type>text</>)</literal>
|
||||
</entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Convert xlog location string to filename</entry>
|
||||
<entry>Convert transaction log location string to file name</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -10290,7 +10290,7 @@ SELECT set_config('log_statement_stats', 'off', false);
|
||||
arbitrary user-defined label for the backup. (Typically this would be
|
||||
the name under which the backup dump file will be stored.) The function
|
||||
writes a backup label file into the database cluster's data directory,
|
||||
and then returns the backup's starting xlog location as text. The user
|
||||
and then returns the backup's starting transaction log location as text. The user
|
||||
need not pay any attention to this result value, but it is provided in
|
||||
case it is of use.
|
||||
<programlisting>
|
||||
@ -10305,33 +10305,33 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
<para>
|
||||
<function>pg_stop_backup</> removes the label file created by
|
||||
<function>pg_start_backup</>, and instead creates a backup history file in
|
||||
the xlog archive area. The history file includes the label given to
|
||||
<function>pg_start_backup</>, the starting and ending xlog locations for
|
||||
the transaction log archive area. The history file includes the label given to
|
||||
<function>pg_start_backup</>, the starting and ending transaction log locations for
|
||||
the backup, and the starting and ending times of the backup. The return
|
||||
value is the backup's ending xlog location (which again may be of little
|
||||
interest). After noting the ending location, the current xlog insertion
|
||||
point is automatically advanced to the next xlog file, so that the
|
||||
ending xlog file can be archived immediately to complete the backup.
|
||||
value is the backup's ending transaction log location (which again may be of little
|
||||
interest). After noting the ending location, the current transaction log insertion
|
||||
point is automatically advanced to the next transaction log file, so that the
|
||||
ending transaction log file can be archived immediately to complete the backup.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_switch_xlog</> moves to the next xlog file, allowing the
|
||||
<function>pg_switch_xlog</> moves to the next transaction log file, allowing the
|
||||
current file to be archived (assuming you are using continuous archiving).
|
||||
The result is the ending xlog location within the just-completed xlog file.
|
||||
If there has been no xlog activity since the last xlog switch,
|
||||
The result is the ending transaction log location within the just-completed transaction log file.
|
||||
If there has been no transaction log activity since the last transaction log switch,
|
||||
<function>pg_switch_xlog</> does nothing and returns the end location
|
||||
of the previous xlog file.
|
||||
of the previous transaction log file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>pg_current_xlog_location</> displays the current xlog write
|
||||
<function>pg_current_xlog_location</> displays the current transaction log write
|
||||
location in the same format used by the above functions. Similarly
|
||||
<function>pg_current_xlog_insert_location</> displays the current xlog
|
||||
insertion point. The insertion point is the <quote>logical</> end of xlog
|
||||
<function>pg_current_xlog_insert_location</> displays the current transaction log
|
||||
insertion point. The insertion point is the <quote>logical</> end of transaction log
|
||||
at any instant, while the write location is the end of what has actually
|
||||
been written out from the server's internal buffers. The write location
|
||||
is the end of what can be examined from outside the server, and is usually
|
||||
what you want if you are interested in archiving partially-complete xlog
|
||||
what you want if you are interested in archiving partially-complete transaction log
|
||||
files. The insertion point is made available primarily for server
|
||||
debugging purposes. These are both read-only operations and do not
|
||||
require superuser permissions.
|
||||
@ -10339,7 +10339,7 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
|
||||
<para>
|
||||
You can use <function>pg_xlogfile_name_offset</> to extract the
|
||||
corresponding xlog filename and byte offset from the results of any of the
|
||||
corresponding transaction log file name and byte offset from the results of any of the
|
||||
above functions. For example:
|
||||
<programlisting>
|
||||
postgres=# select * from pg_xlogfile_name_offset(pg_stop_backup());
|
||||
@ -10348,10 +10348,10 @@ postgres=# select * from pg_xlogfile_name_offset(pg_stop_backup());
|
||||
00000001000000000000000D | 4039624
|
||||
(1 row)
|
||||
</programlisting>
|
||||
Similarly, <function>pg_xlogfile_name</> extracts just the xlog filename.
|
||||
When the given xlog location is exactly at an xlog file boundary, both
|
||||
these functions return the name of the preceding xlog file.
|
||||
This is usually the desired behavior for managing xlog archiving
|
||||
Similarly, <function>pg_xlogfile_name</> extracts just the transaction log file name.
|
||||
When the given transction log location is exactly at an transaction log file boundary, both
|
||||
these functions return the name of the preceding transaction log file.
|
||||
This is usually the desired behavior for managing transaction log archiving
|
||||
behavior, since the preceding file is the last one that currently
|
||||
needs to be archived.
|
||||
</para>
|
||||
@ -10574,7 +10574,7 @@ postgres=# select * from pg_xlogfile_name_offset(pg_stop_backup());
|
||||
<function>pg_stat_file</> returns a record containing the file
|
||||
size, last accessed time stamp, last modified time stamp,
|
||||
last file status change time stamp (Unix platforms only),
|
||||
file creation timestamp (Windows only), and a <type>boolean</type>
|
||||
file creation time stamp (Windows only), and a <type>boolean</type>
|
||||
indicating if it is a directory. Typical usages include:
|
||||
<programlisting>
|
||||
SELECT * FROM pg_stat_file('filename');
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.26 2006/03/10 19:10:48 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.27 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="GiST">
|
||||
<title>GiST Indexes</title>
|
||||
@ -199,7 +199,7 @@
|
||||
<varlistentry>
|
||||
<term>cube</term>
|
||||
<listitem>
|
||||
<para>Indexing for multi-dimensional cubes</para>
|
||||
<para>Indexing for multidimensional cubes</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/history.sgml,v 1.28 2006/03/10 19:10:48 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/history.sgml,v 1.29 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<sect1 id="history">
|
||||
<title>A Brief History of <productname>PostgreSQL</productname></title>
|
||||
@ -31,7 +31,7 @@
|
||||
Office (<acronym>ARO</acronym>), the National Science Foundation
|
||||
(<acronym>NSF</acronym>), and ESL, Inc. The implementation of
|
||||
<productname>POSTGRES</productname> began in 1986. The initial
|
||||
concepts for the system were presented in <xref linkend="STON86">
|
||||
concepts for the system were presented in <xref linkend="STON86">,
|
||||
and the definition of the initial data model appeared in <xref
|
||||
linkend="ROWE87">. The design of the rule system at that time was
|
||||
described in <xref linkend="STON87a">. The rationale and
|
||||
@ -47,7 +47,7 @@
|
||||
<xref linkend="STON90a">, was released to a few external users in
|
||||
June 1989. In response to a critique of the first rule system
|
||||
(<xref linkend="STON89">), the rule system was redesigned (<xref
|
||||
linkend="STON90b">) and Version 2 was released in June 1990 with
|
||||
linkend="STON90b">), and Version 2 was released in June 1990 with
|
||||
the new rule system. Version 3 appeared in 1991 and added support
|
||||
for multiple storage managers, an improved query executor, and a
|
||||
rewritten rule system. For the most part, subsequent releases
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.64 2006/09/18 12:11:36 teodor Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.65 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indexes</title>
|
||||
@ -254,7 +254,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
indexing strategy.
|
||||
As an example, the standard distribution of
|
||||
<productname>PostgreSQL</productname> includes GIN operator classes
|
||||
for one-dimentional arrays, which support indexed
|
||||
for one-dimensional arrays, which support indexed
|
||||
queries using these operators:
|
||||
|
||||
<simplelist>
|
||||
@ -267,7 +267,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
(See <xref linkend="functions-array"> for the meaning of
|
||||
these operators.)
|
||||
Other GIN operator classes are available in the <literal>contrib</>
|
||||
tsearch2 and intarray modules. For more information see <xref linkend="GIN">.
|
||||
<literal>tsearch2</literal> and <literal>intarray</literal> modules. For more information see <xref linkend="GIN">.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.28 2006/10/03 01:03:53 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.29 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="information-schema">
|
||||
<title>The Information Schema</title>
|
||||
@ -2313,7 +2313,7 @@ ORDER BY c.ordinal_position;
|
||||
<entry>
|
||||
<literal>IN</literal> for input parameter,
|
||||
<literal>OUT</literal> for output parameter,
|
||||
and <literal>INOUT</literal> for input/ouput parameter.
|
||||
and <literal>INOUT</literal> for input/output parameter.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.218 2006/10/21 18:25:01 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.219 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="libpq">
|
||||
<title><application>libpq</application> - C Library</title>
|
||||
@ -3805,8 +3805,9 @@ It is good practice not to send the original cleartext password in such a
|
||||
command, because it might be exposed in command logs, activity displays,
|
||||
and so on. Instead, use this function to convert the password to encrypted
|
||||
form before it is sent. The arguments are the cleartext password, and the SQL
|
||||
name of the user it is for. The return value is a malloc'd string, or NULL if
|
||||
out-of-memory. The caller may assume the string doesn't contain any special
|
||||
name of the user it is for. The return value is a string allocated by
|
||||
<function>malloc</function>, or <symbol>NULL</symbol> if out of memory.
|
||||
The caller may assume the string doesn't contain any special
|
||||
characters that would require escaping. Use <function>PQfreemem</> to free
|
||||
the result when done with it.
|
||||
</para>
|
||||
@ -4232,7 +4233,7 @@ current connection parameters will be used. (Therefore, put more-specific
|
||||
entries first when you are using wildcards.)
|
||||
If an entry needs to contain <literal>:</literal> or
|
||||
<literal>\</literal>, escape this character with <literal>\</literal>.
|
||||
A hostname of <literal>localhost</> matches both TCP (hostname
|
||||
A host name of <literal>localhost</> matches both TCP (hostname
|
||||
<literal>localhost</>) and Unix domain socket (<literal>pghost</> empty or the
|
||||
default socket directory) connections coming from the local machine.
|
||||
</para>
|
||||
@ -4380,7 +4381,7 @@ ldap://ldap.mycompany.com/dc=mycompany,dc=com?uniqueMember?one?(cn=mydatabase)
|
||||
fail if the server does not present a certificate; therefore, to
|
||||
use this feature the server must also have a <filename>root.crt</> file.
|
||||
Certificate Revocation List (CRL) entries are also checked if the file
|
||||
<filename>~/.postgresql/root.crl</filename> exists (%APPDATA%\postgresql\root.crl
|
||||
<filename>~/.postgresql/root.crl</filename> exists (<filename>%APPDATA%\postgresql\root.crl</filename>
|
||||
on Microsoft Windows).
|
||||
</para>
|
||||
|
||||
@ -4430,7 +4431,7 @@ int PQisthreadsafe();
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Returns 1 if the <application>libpq</application> is thead-safe and
|
||||
Returns 1 if the <application>libpq</application> is thread-safe and
|
||||
0 if it is not.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.41 2006/09/16 00:30:14 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/lobj.sgml,v 1.42 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="largeObjects">
|
||||
<title id="largeObjects-title">Large Objects</title>
|
||||
@ -95,7 +95,7 @@ Oid lo_creat(PGconn *conn, int mode);
|
||||
<indexterm><primary>lo_creat</></>
|
||||
creates a new large object.
|
||||
The return value is the OID that was assigned to the new large object,
|
||||
or InvalidOid (zero) on failure.
|
||||
or <symbol>InvalidOid</symbol> (zero) on failure.
|
||||
|
||||
<replaceable class="parameter">mode</replaceable> is unused and
|
||||
ignored as of <productname>PostgreSQL</productname> 8.1; however, for
|
||||
@ -123,16 +123,16 @@ Oid lo_create(PGconn *conn, Oid lobjId);
|
||||
specified by <replaceable class="parameter">lobjId</replaceable>;
|
||||
if so, failure occurs if that OID is already in use for some large
|
||||
object. If <replaceable class="parameter">lobjId</replaceable>
|
||||
is InvalidOid (zero) then <function>lo_create</> assigns an unused
|
||||
is <symbol>InvalidOid</symbol> (zero) then <function>lo_create</> assigns an unused
|
||||
OID (this is the same behavior as <function>lo_creat</>).
|
||||
The return value is the OID that was assigned to the new large object,
|
||||
or InvalidOid (zero) on failure.
|
||||
or <symbol>InvalidOid</symbol> (zero) on failure.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<function>lo_create</> is new as of <productname>PostgreSQL</productname>
|
||||
8.1; if this function is run against an older server version, it will
|
||||
fail and return InvalidOid.
|
||||
fail and return <symbol>InvalidOid</symbol>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -156,9 +156,9 @@ Oid lo_import(PGconn *conn, const char *filename);
|
||||
specifies the operating system name of
|
||||
the file to be imported as a large object.
|
||||
The return value is the OID that was assigned to the new large object,
|
||||
or InvalidOid (zero) on failure.
|
||||
or <symbol>InvalidOid</symbol> (zero) on failure.
|
||||
Note that the file is read by the client interface library, not by
|
||||
the server; so it must exist in the client filesystem and be readable
|
||||
the server; so it must exist in the client file system and be readable
|
||||
by the client application.
|
||||
</para>
|
||||
</sect2>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.62 2006/09/16 00:30:14 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.63 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="maintenance">
|
||||
<title>Routine Database Maintenance Tasks</title>
|
||||
@ -90,9 +90,10 @@
|
||||
|
||||
<para>
|
||||
The standard form of <command>VACUUM</> can run in parallel with production
|
||||
database operations. Commands such as SELECTs, INSERTs, UPDATEs and DELETEs
|
||||
database operations. Commands such as <command>SELECT</command>,
|
||||
<command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command>
|
||||
will continue to function as normal, though you will not be able to modify the
|
||||
definition of a table with commands such as ALTER TABLE ADD COLUMN
|
||||
definition of a table with commands such as <command>ALTER TABLE ADD COLUMN</command>
|
||||
while it is being vacuumed.
|
||||
Beginning in <productname>PostgreSQL</productname> 8.0, there are
|
||||
configuration parameters that can be adjusted to further reduce the
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.57 2006/09/16 00:30:14 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.58 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="plperl">
|
||||
<title>PL/Perl - Perl Procedural Language</title>
|
||||
@ -21,7 +21,7 @@
|
||||
within stored functions, of the manyfold <quote>string
|
||||
munging</quote> operators and functions available for Perl. Parsing
|
||||
complex strings may be be easier using Perl than it is with the
|
||||
string functions and control structures provided in PL/pgsql.</para>
|
||||
string functions and control structures provided in PL/pgSQL.</para>
|
||||
|
||||
<para>
|
||||
To install PL/Perl in a particular database, use
|
||||
@ -188,7 +188,7 @@ SELECT * FROM perl_row();
|
||||
</programlisting>
|
||||
|
||||
Any columns in the declared result data type that are not present in the
|
||||
hash will be returned as NULLs.
|
||||
hash will be returned as null values.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.100 2006/09/16 00:30:14 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.101 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
|
||||
@ -176,7 +176,7 @@ $$ LANGUAGE plpgsql;
|
||||
client and server </para></listitem>
|
||||
|
||||
<listitem><para> Intermediate results that the client does not
|
||||
need do not need to be marshalled or transferred between server
|
||||
need do not need to be marshaled or transferred between server
|
||||
and client </para></listitem>
|
||||
|
||||
<listitem><para> There is no need for additional rounds of query
|
||||
@ -1066,7 +1066,7 @@ tax := subtotal * 0.06;
|
||||
Any <application>PL/pgSQL</application> variable name appearing
|
||||
in the query text is replaced by a parameter symbol, and then the
|
||||
current value of the variable is provided as the parameter value
|
||||
at runtime. This allows the same textual query to do different
|
||||
at run time. This allows the same textual query to do different
|
||||
things in different calls of the function.
|
||||
</para>
|
||||
|
||||
@ -1182,7 +1182,7 @@ DELETE ... RETURNING <replaceable>expressions</replaceable> INTO <optional>STRIC
|
||||
substituted into the rest of the query as usual.
|
||||
This works for <command>SELECT</>,
|
||||
<command>INSERT</>/<command>UPDATE</>/<command>DELETE</> with
|
||||
<literal>RETURNING</>, and utility commands that return rowset
|
||||
<literal>RETURNING</>, and utility commands that return row-set
|
||||
results (such as <command>EXPLAIN</>).
|
||||
Except for the <literal>INTO</> clause, the SQL command is the same
|
||||
as it would be written outside <application>PL/pgSQL</application>.
|
||||
@ -2738,7 +2738,7 @@ RAISE EXCEPTION 'Nonexistent ID --> %', user_id;
|
||||
|
||||
<para>
|
||||
<command>RAISE EXCEPTION</command> presently always generates
|
||||
the same SQLSTATE code, <literal>P0001</>, no matter what message
|
||||
the same <varname>SQLSTATE</varname> code, <literal>P0001</>, no matter what message
|
||||
it is invoked with. It is possible to trap this exception with
|
||||
<literal>EXCEPTION ... WHEN RAISE_EXCEPTION THEN ...</> but there
|
||||
is no way to tell one <command>RAISE</> from another.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.35 2006/10/21 18:33:05 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.36 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="plpython">
|
||||
<title>PL/Python - Python Procedural Language</title>
|
||||
@ -65,7 +65,7 @@ $$ LANGUAGE plpythonu;
|
||||
<varname>args[]</varname>; named arguments are also passed as ordinary
|
||||
variables to the Python script. The result is returned from the Python code
|
||||
in the usual way, with <literal>return</literal> or
|
||||
<literal>yield</literal> (in case of a resultset statement).
|
||||
<literal>yield</literal> (in case of a result-set statement).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.37 2006/10/22 03:03:41 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.38 2006/10/23 18:10:31 petere Exp $ -->
|
||||
|
||||
<chapter id="queries">
|
||||
<title>Queries</title>
|
||||
@ -1367,7 +1367,7 @@ VALUES ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) [, ..
|
||||
Each parenthesized list of expressions generates a row in the table.
|
||||
The lists must all have the same number of elements (i.e., the number
|
||||
of columns in the table), and corresponding entries in each list must
|
||||
have compatible datatypes. The actual datatype assigned to each column
|
||||
have compatible data types. The actual data type assigned to each column
|
||||
of the result is determined using the same rules as for <literal>UNION</>
|
||||
(see <xref linkend="typeconv-union-case">).
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.91 2006/10/13 21:43:18 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.92 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -740,7 +740,7 @@ ALTER TABLE foo
|
||||
|
||||
<para>
|
||||
The same, when the column has a default expression that won't automatically
|
||||
cast to the new datatype:
|
||||
cast to the new data type:
|
||||
<programlisting>
|
||||
ALTER TABLE foo
|
||||
ALTER COLUMN foo_timestamp DROP DEFAULT,
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/comment.sgml,v 1.32 2006/09/16 00:30:17 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/comment.sgml,v 1.33 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -206,7 +206,7 @@ COMMENT ON
|
||||
connected to a database can see all the comments for objects in
|
||||
that database (although only superusers can change comments for
|
||||
objects that they don't own). For shared objects such as
|
||||
databases, roles, and tablespaces comments are stored gloablly
|
||||
databases, roles, and tablespaces comments are stored globally
|
||||
and any user connected to any database can see all the comments
|
||||
for shared objects. Therefore, don't put security-critical
|
||||
information in comments.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.44 2006/09/16 00:30:17 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.45 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -258,7 +258,7 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
|
||||
DELETE</literal> to always fire before the delete action, even a cascading
|
||||
one. This is considered more consistent. There is also unpredictable
|
||||
behavior when <literal>BEFORE</literal> triggers modify rows that are later
|
||||
to be modified by referential actions. This can lead to contraint violations
|
||||
to be modified by referential actions. This can lead to constraint violations
|
||||
or stored data that does not honor the referential constraint.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.28 2006/09/16 00:30:18 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/drop_type.sgml,v 1.29 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -94,7 +94,7 @@ DROP TYPE box;
|
||||
|
||||
<para>
|
||||
This command is similar to the corresponding command in the SQL
|
||||
standard, aapart from the <literal>IF EXISTS</>
|
||||
standard, apart from the <literal>IF EXISTS</>
|
||||
option, which is a <productname>PostgreSQL</> extension.
|
||||
But note that the <command>CREATE TYPE</command> command
|
||||
and the data type extension mechanisms in
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/insert.sgml,v 1.33 2006/09/18 19:54:01 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/insert.sgml,v 1.34 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -234,7 +234,7 @@ INSERT INTO films DEFAULT VALUES;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To insert multiple rows using the multi-row <command>VALUES</> syntax:
|
||||
To insert multiple rows using the multirow <command>VALUES</> syntax:
|
||||
|
||||
<programlisting>
|
||||
INSERT INTO films (code, title, did, date_prod, kind) VALUES
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_config-ref.sgml,v 1.24 2006/09/16 00:30:19 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_config-ref.sgml,v 1.25 2006/10/23 18:10:32 petere Exp $ -->
|
||||
|
||||
<refentry id="app-pgconfig">
|
||||
<refmeta>
|
||||
@ -177,7 +177,7 @@
|
||||
<term><option>--cc</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the CC macro that was used for building
|
||||
Print the value of the <varname>CC</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows the C compiler used.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -187,7 +187,7 @@
|
||||
<term><option>--cppflags</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the CPPFLAGS macro that was used for building
|
||||
Print the value of the <varname>CPPFLAGS</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows C compiler switches needed
|
||||
at preprocessing time (typically, <literal>-I</> switches).
|
||||
</para>
|
||||
@ -198,7 +198,7 @@
|
||||
<term><option>--cflags</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the CFLAGS macro that was used for building
|
||||
Print the value of the <varname>CFLAGS</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows C compiler switches.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -208,7 +208,7 @@
|
||||
<term><option>--cflags_sl</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the CFLAGS_SL macro that was used for building
|
||||
Print the value of the <varname>CFLAGS_SL</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows extra C compiler switches
|
||||
used for building shared libraries.
|
||||
</para>
|
||||
@ -219,7 +219,7 @@
|
||||
<term><option>--ldflags</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the LDFLAGS macro that was used for building
|
||||
Print the value of the <varname>LDFLAGS</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows linker switches.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -229,7 +229,7 @@
|
||||
<term><option>--ldflags_sl</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the LDFLAGS_SL macro that was used for building
|
||||
Print the value of the <varname>LDFLAGS_SL</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This shows linker switches
|
||||
used for building shared libraries.
|
||||
</para>
|
||||
@ -240,7 +240,7 @@
|
||||
<term><option>--libs</option></>
|
||||
<listitem>
|
||||
<para>
|
||||
Print the value of the LIBS macro that was used for building
|
||||
Print the value of the <varname>LIBS</varname> variable that was used for building
|
||||
<productname>PostgreSQL</>. This normally contains <literal>-l</>
|
||||
switches for external libraries linked into <productname>PostgreSQL</>.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.90 2006/10/09 23:36:58 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.91 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -748,7 +748,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Because <application>pg_dump</application> is used to tranfer data
|
||||
Because <application>pg_dump</application> is used to transfer data
|
||||
to newer versions of <productname>PostgreSQL</>, the output of
|
||||
<application>pg_dump</application> can be loaded into
|
||||
newer <productname>PostgreSQL</> databases. It also can read older
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.171 2006/10/09 23:31:29 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.172 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -2772,7 +2772,7 @@ Field separator is "oo".
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Set the console font to <quote>Lucida Console</>, because the
|
||||
Set the console font to <literal>Lucida Console</>, because the
|
||||
raster font does not work with the ANSI code page.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/values.sgml,v 1.1 2006/09/18 19:54:01 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/values.sgml,v 1.2 2006/10/23 18:10:32 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -202,9 +202,9 @@ UPDATE employees SET salary = salary * v.increase
|
||||
|
||||
<para>
|
||||
When <command>VALUES</> is used in <command>INSERT</>, the values are all
|
||||
automatically coerced to the datatype of the corresponding destination
|
||||
automatically coerced to the data type of the corresponding destination
|
||||
column. When it's used in other contexts, it may be necessary to specify
|
||||
the correct datatype. If the entries are all quoted literal constants,
|
||||
the correct data type. If the entries are all quoted literal constants,
|
||||
coercing the first is sufficient to determine the assumed type for all:
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.479 2006/10/21 18:41:53 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.480 2006/10/23 18:10:31 petere Exp $ -->
|
||||
<!--
|
||||
|
||||
Typical markup:
|
||||
@ -55,7 +55,7 @@ links to the main documentation.
|
||||
<listitem>
|
||||
<para>
|
||||
Query language enhancements including <command>INSERT/UPDATE/DELETE
|
||||
RETURNING</command>, multi-row <literal>VALUES</literal> lists, and
|
||||
RETURNING</command>, multirow <literal>VALUES</literal> lists, and
|
||||
optional target-table alias in
|
||||
<command>UPDATE</>/<command>DELETE</command>
|
||||
</para>
|
||||
@ -147,7 +147,7 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Many /contrib improvements
|
||||
Many <filename>contrib/</filename> improvements
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -192,7 +192,7 @@ links to the main documentation.
|
||||
constructor syntax</link> (<literal>ROW(...)</>) so that
|
||||
list elements <literal>foo.*</> will be expanded to a list
|
||||
of their member fields, rather than creating a nested
|
||||
rowtype field as formerly (Tom)
|
||||
row type field as formerly (Tom)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -298,13 +298,13 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Deprecate use of <application>postmaster</> symlink (Peter)
|
||||
Deprecate use of <application>postmaster</> symbolic link (Peter)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>postmaster</> and <application>postgres</>
|
||||
commands now act identically, with the behavior determined
|
||||
by switches. The <application>postmaster</> symlink is
|
||||
by command-line options. The <application>postmaster</> symbolic link is
|
||||
kept for compatibility, but is not really needed.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -365,7 +365,7 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Improve cost estimation for nestloop index scans (Tom)
|
||||
Improve cost estimation for nested-loop index scans (Tom)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -400,7 +400,7 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
In /contrib/xml2, rename <function>xml_valid()</> to
|
||||
In <filename>contrib/xml2/<filename>, rename <function>xml_valid()</> to
|
||||
<function>xml_is_well_formed()</> (Tom)
|
||||
</para>
|
||||
|
||||
@ -413,15 +413,16 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Remove /contrib/ora2pg, now at <ulink
|
||||
Remove <filename>contrib/ora2pg/<filename>, now at <ulink
|
||||
url="http://www.samse.fr/GPL/ora2pg"></ulink>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Remove contrib modules that have been migrated to pgfoundry:
|
||||
adddepend, dbase, dbmirror, fulltextindex, mac, userlock
|
||||
Remove contrib modules that have been migrated to PgFoundry:
|
||||
<filename>adddepend</>, <filename>dbase</>, <filename>dbmirror</>,
|
||||
<filename>fulltextindex</>, <filename>mac</>, <filename>userlock</>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -506,7 +507,7 @@ links to the main documentation.
|
||||
<para>
|
||||
This leaves extra free space in each table or index page,
|
||||
allowing improved performance as the database grows. This
|
||||
is particularly valuable to maintain <command>CLUSTER</>ing.
|
||||
is particularly valuable to maintain clustering.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -600,7 +601,7 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Speed up vacuuming of btree indexes (Heikki Linnakangas,
|
||||
Speed up vacuuming of B-Tree indexes (Heikki Linnakangas,
|
||||
Tom)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -621,7 +622,7 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Remove dead index entries before btree page split (Junji
|
||||
Remove dead index entries before B-Tree page split (Junji
|
||||
Teramoto)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -636,16 +637,16 @@ links to the main documentation.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow a forced switch to a new xlog file (Simon, Tom)
|
||||
Allow a forced switch to a new transaction log file (Simon, Tom)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This is valuable for keeping warm standby slave servers
|
||||
in sync with the master. xlog file switching now also happens
|
||||
in sync with the master. Transaction log file switching now also happens
|
||||
automatically during <link
|
||||
linkend="functions-admin"><function>pg_stop_backup()</></link>.
|
||||
This ensures that all
|
||||
xlog files needed for recovery can be archived immediately.
|
||||
transaction log files needed for recovery can be archived immediately.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -655,7 +656,7 @@ links to the main documentation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Add functions for interrogating the current xlog insertion
|
||||
Add functions for interrogating the current transaction log insertion
|
||||
point and determining <acronym>WAL</> filenames from the
|
||||
hex <acronym>WAL</> locations displayed by <link
|
||||
linkend="functions-admin"><function>pg_stop_backup()</></link>
|
||||
@ -681,7 +682,7 @@ links to the main documentation.
|
||||
<para>
|
||||
Add <link
|
||||
linkend="guc-archive-timeout"><varname>archive_timeout</></link>
|
||||
to force xlog file switches at a given interval (Simon)
|
||||
to force transaction log file switches at a given interval (Simon)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -2653,7 +2654,7 @@ MIN/MAX optimization (Tom)</para></listitem>
|
||||
<listitem><para>Fix crash from using and modifying a plpgsql function in the
|
||||
same transaction</para></listitem>
|
||||
|
||||
<listitem><para>Fix WAL replay for case where a btree index has been
|
||||
<listitem><para>Fix WAL replay for case where a B-Tree index has been
|
||||
truncated</para></listitem>
|
||||
|
||||
<listitem><para>Fix <literal>SIMILAR TO</> for patterns involving
|
||||
@ -3776,7 +3777,7 @@ psql -t -f fixseq.sql db1 | psql -e db1
|
||||
</para>
|
||||
<para>
|
||||
This prevents a large number of <filename>*.backup</> files from
|
||||
existing in <filename>/pg_xlog</>.
|
||||
existing in <filename>pg_xlog/</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.19 2006/09/16 00:30:15 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.20 2006/10/23 18:10:32 petere Exp $ -->
|
||||
|
||||
<chapter id="source">
|
||||
<title>PostgreSQL Coding Conventions</title>
|
||||
@ -219,7 +219,7 @@ elog(level, "format string", ...);
|
||||
<programlisting>
|
||||
ereport(level, (errmsg_internal("format string", ...)));
|
||||
</programlisting>
|
||||
Notice that the SQLSTATE errcode is always defaulted, and the message
|
||||
Notice that the SQLSTATE error code is always defaulted, and the message
|
||||
string is not included in the internationalization message dictionary.
|
||||
Therefore, <function>elog</> should be used only for internal errors and
|
||||
low-level debug logging. Any message that is likely to be of interest to
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.48 2006/09/10 20:56:42 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.49 2006/10/23 18:10:32 petere Exp $ -->
|
||||
|
||||
<chapter id="spi">
|
||||
<title>Server Programming Interface</title>
|
||||
@ -369,7 +369,7 @@ SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
|
||||
then you may use the
|
||||
global pointer <literal>SPITupleTable *SPI_tuptable</literal> to
|
||||
access the result rows. Some utility commands (such as
|
||||
<command>EXPLAIN</>) also return rowsets, and <literal>SPI_tuptable</>
|
||||
<command>EXPLAIN</>) also return row sets, and <literal>SPI_tuptable</>
|
||||
will contain the result in these cases too.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.40 2006/09/16 00:30:16 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.41 2006/10/23 18:10:32 petere Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Reliability and the Write-Ahead Log</title>
|
||||
@ -85,8 +85,8 @@
|
||||
permanent storage <emphasis>before</> modifying the actual page on
|
||||
disk. By doing this, during crash recovery <productname>PostgreSQL</> can
|
||||
restore partially-written pages. If you have a battery-backed disk
|
||||
controller or file-system software (e.g., Reiser4) that prevents partial
|
||||
page writes, you can turn off this page imaging by using the
|
||||
controller or file-system software that prevents partial page writes
|
||||
(e.g., ReiserFS 4), you can turn off this page imaging by using the
|
||||
<xref linkend="guc-full-page-writes"> parameter.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.51 2006/09/21 15:09:38 teodor Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.52 2006/10/23 18:10:32 petere Exp $ -->
|
||||
|
||||
<sect1 id="xindex">
|
||||
<title>Interfacing Extensions To Indexes</title>
|
||||
@ -387,7 +387,7 @@
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>consistent - determine whether key satifies the
|
||||
<entry>consistent - determine whether key satisfies the
|
||||
query qualifier</entry>
|
||||
<entry>1</entry>
|
||||
</row>
|
||||
|
Loading…
x
Reference in New Issue
Block a user