mirror of
https://github.com/postgres/postgres.git
synced 2025-06-27 23:21:58 +03:00
Spell and markup checking
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.34 2010/04/03 07:22:52 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.35 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="overview">
|
||||
<title>Overview of PostgreSQL Internals</title>
|
||||
@ -463,7 +463,7 @@
|
||||
needed, plus any auxiliary steps needed, such as sort nodes or
|
||||
aggregate-function calculation nodes. Most of these plan node
|
||||
types have the additional ability to do <firstterm>selection</>
|
||||
(discarding rows that do not meet a specified boolean condition)
|
||||
(discarding rows that do not meet a specified Boolean condition)
|
||||
and <firstterm>projection</> (computation of a derived column set
|
||||
based on given column values, that is, evaluation of scalar
|
||||
expressions where needed). One of the responsibilities of the
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.23 2010/01/05 01:06:55 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.24 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="bki">
|
||||
<title><acronym>BKI</acronym> Backend Interface</title>
|
||||
@ -122,7 +122,7 @@
|
||||
The table is created as shared if <literal>shared_relation</> is
|
||||
specified.
|
||||
It will have OIDs unless <literal>without_oids</> is specified.
|
||||
The table's rowtype OID (<structname>pg_type</> OID) can optionally
|
||||
The table's row type OID (<structname>pg_type</> OID) can optionally
|
||||
be specified via the <literal>rowtype_oid</> clause; if not specified,
|
||||
an OID is automatically generated for it. (The <literal>rowtype_oid</>
|
||||
clause is useless if <literal>bootstrap</> is specified, but it can be
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/btree-gin.sgml,v 1.1 2009/03/25 23:20:01 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/btree-gin.sgml,v 1.2 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="btree-gin">
|
||||
<title>btree_gin</title>
|
||||
@ -9,7 +9,7 @@
|
||||
|
||||
<para>
|
||||
<filename>btree_gin</> provides sample GIN operator classes that
|
||||
implement B-Tree equivalent behavior for the data types
|
||||
implement B-tree equivalent behavior for the data types
|
||||
<type>int2</>, <type>int4</>, <type>int8</>, <type>float4</>,
|
||||
<type>float8</>, <type>timestamp with time zone</>,
|
||||
<type>timestamp without time zone</>, <type>time with time zone</>,
|
||||
@ -21,12 +21,12 @@
|
||||
|
||||
<para>
|
||||
In general, these operator classes will not outperform the equivalent
|
||||
standard btree index methods, and they lack one major feature of the
|
||||
standard btree code: the ability to enforce uniqueness. However,
|
||||
standard B-tree index methods, and they lack one major feature of the
|
||||
standard B-tree code: the ability to enforce uniqueness. However,
|
||||
they are useful for GIN testing and as a base for developing other
|
||||
GIN operator classes. Also, for queries that test both a GIN-indexable
|
||||
column and a btree-indexable column, it might be more efficient to create
|
||||
a multi-column GIN index that uses one of these opclasses than to create
|
||||
column and a B-tree-indexable column, it might be more efficient to create
|
||||
a multicolumn GIN index that uses one of these operator classes than to create
|
||||
two separate indexes that would have to be combined via bitmap ANDing.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/btree-gist.sgml,v 1.7 2010/08/03 15:15:31 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/btree-gist.sgml,v 1.8 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="btree-gist">
|
||||
<title>btree_gist</title>
|
||||
@ -9,7 +9,7 @@
|
||||
|
||||
<para>
|
||||
<filename>btree_gist</> provides sample GiST operator classes that
|
||||
implement B-Tree equivalent behavior for the data types
|
||||
implement B-tree equivalent behavior for the data types
|
||||
<type>int2</>, <type>int4</>, <type>int8</>, <type>float4</>,
|
||||
<type>float8</>, <type>numeric</>, <type>timestamp with time zone</>,
|
||||
<type>timestamp without time zone</>, <type>time with time zone</>,
|
||||
@ -21,8 +21,8 @@
|
||||
|
||||
<para>
|
||||
In general, these operator classes will not outperform the equivalent
|
||||
standard btree index methods, and they lack one major feature of the
|
||||
standard btree code: the ability to enforce uniqueness. However,
|
||||
standard B-tree index methods, and they lack one major feature of the
|
||||
standard B-tree code: the ability to enforce uniqueness. However,
|
||||
they are useful for GiST testing and as a base for developing other
|
||||
GiST operator classes.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.225 2010/04/03 07:22:52 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.226 2010/08/17 04:37:20 petere Exp $ -->
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
-->
|
||||
@ -344,8 +344,8 @@
|
||||
<entry>
|
||||
The initial value of the transition state. This is a text
|
||||
field containing the initial value in its external string
|
||||
representation. If this field is NULL, the transition state
|
||||
value starts out NULL
|
||||
representation. If this field is null, the transition state
|
||||
value starts out null.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -461,7 +461,7 @@
|
||||
<entry><structfield>amsearchnulls</structfield></entry>
|
||||
<entry><type>bool</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Does the access method support IS NULL/NOT NULL searches?</entry>
|
||||
<entry>Does the access method support <literal>IS NULL</>/<literal>NOT NULL</> searches?</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -892,7 +892,7 @@
|
||||
The exact meaning of positive values is data type-dependent.
|
||||
For scalar data types, <structfield>attstattarget</structfield>
|
||||
is both the target number of <quote>most common values</quote>
|
||||
to collect, and the target number of histogram bins to create
|
||||
to collect, and the target number of histogram bins to create.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -913,7 +913,7 @@
|
||||
<entry>
|
||||
The number of the column. Ordinary columns are numbered from 1
|
||||
up. System columns, such as <structfield>oid</structfield>,
|
||||
have (arbitrary) negative numbers
|
||||
have (arbitrary) negative numbers.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -924,7 +924,7 @@
|
||||
<entry>
|
||||
Number of dimensions, if the column is an array type; otherwise 0.
|
||||
(Presently, the number of dimensions of an array is not enforced,
|
||||
so any nonzero value effectively means <quote>it's an array</>)
|
||||
so any nonzero value effectively means <quote>it's an array</>.)
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -948,7 +948,7 @@
|
||||
supplied at table creation time (for example, the maximum
|
||||
length of a <type>varchar</type> column). It is passed to
|
||||
type-specific input functions and length coercion functions.
|
||||
The value will generally be -1 for types that do not need <structfield>atttypmod</>
|
||||
The value will generally be -1 for types that do not need <structfield>atttypmod</>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -968,7 +968,7 @@
|
||||
<entry>
|
||||
Normally a copy of <literal>pg_type.typstorage</> of this
|
||||
column's type. For TOAST-able data types, this can be altered
|
||||
after column creation to control storage policy
|
||||
after column creation to control storage policy.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -987,7 +987,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
This represents a not-null constraint. It is possible to
|
||||
change this column to enable or disable the constraint
|
||||
change this column to enable or disable the constraint.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -998,7 +998,7 @@
|
||||
<entry>
|
||||
This column has a default value, in which case there will be a
|
||||
corresponding entry in the <structname>pg_attrdef</structname>
|
||||
catalog that actually defines the value
|
||||
catalog that actually defines the value.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1009,7 +1009,7 @@
|
||||
<entry>
|
||||
This column has been dropped and is no longer valid. A dropped
|
||||
column is still physically present in the table, but is
|
||||
ignored by the parser and so cannot be accessed via SQL
|
||||
ignored by the parser and so cannot be accessed via SQL.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1019,7 +1019,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
This column is defined locally in the relation. Note that a column can
|
||||
be locally defined and inherited simultaneously
|
||||
be locally defined and inherited simultaneously.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1029,7 +1029,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
The number of direct ancestors this column has. A column with a
|
||||
nonzero number of ancestors cannot be dropped nor renamed
|
||||
nonzero number of ancestors cannot be dropped nor renamed.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1163,7 +1163,7 @@
|
||||
<entry><type>bool</type></entry>
|
||||
<entry>
|
||||
Role can log in. That is, this role can be given as the initial
|
||||
session authorization identifier
|
||||
session authorization identifier.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1172,21 +1172,21 @@
|
||||
<entry><type>int4</type></entry>
|
||||
<entry>
|
||||
For roles that can log in, this sets maximum number of concurrent
|
||||
connections this role can make. -1 means no limit
|
||||
connections this role can make. -1 means no limit.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structfield>rolpassword</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Password (possibly encrypted); NULL if none</entry>
|
||||
<entry>Password (possibly encrypted); null if none</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structfield>rolvaliduntil</structfield></entry>
|
||||
<entry><type>timestamptz</type></entry>
|
||||
<entry>Password expiry time (only used for password authentication);
|
||||
NULL if no expiration</entry>
|
||||
null if no expiration</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -1338,7 +1338,7 @@
|
||||
<literal>a</> means implicitly in assignment
|
||||
to a target column, as well as explicitly.
|
||||
<literal>i</> means implicitly in expressions, as well as the
|
||||
other cases
|
||||
other cases.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -1349,7 +1349,7 @@
|
||||
Indicates how the cast is performed.
|
||||
<literal>f</> means that the function specified in the <structfield>castfunc</> field is used.
|
||||
<literal>i</> means that the input/output functions are used.
|
||||
<literal>b</> means that the types are binary-coercible, thus no conversion is required
|
||||
<literal>b</> means that the types are binary-coercible, thus no conversion is required.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -1487,7 +1487,7 @@
|
||||
<symbol>BLCKSZ</symbol>). This is only an estimate used by the
|
||||
planner. It is updated by <command>VACUUM</command>,
|
||||
<command>ANALYZE</command>, and a few DDL commands such as
|
||||
<command>CREATE INDEX</command>
|
||||
<command>CREATE INDEX</command>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1499,7 +1499,7 @@
|
||||
Number of rows in the table. This is only an estimate used by the
|
||||
planner. It is updated by <command>VACUUM</command>,
|
||||
<command>ANALYZE</command>, and a few DDL commands such as
|
||||
<command>CREATE INDEX</command>
|
||||
<command>CREATE INDEX</command>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1510,7 +1510,7 @@
|
||||
<entry>
|
||||
OID of the TOAST table associated with this table, 0 if none. The
|
||||
TOAST table stores large attributes <quote>out of line</quote> in a
|
||||
secondary table
|
||||
secondary table.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1519,7 +1519,7 @@
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
For a TOAST table, the OID of its index. 0 if not a TOAST table
|
||||
For a TOAST table, the OID of its index. 0 if not a TOAST table.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1539,7 +1539,7 @@
|
||||
<entry>
|
||||
True if this table is shared across all databases in the cluster. Only
|
||||
certain system catalogs (such as <structname>pg_database</structname>)
|
||||
are shared
|
||||
are shared.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1549,7 +1549,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
True if this table is a temporary relation. If so, only the creating
|
||||
session can safely access its contents
|
||||
session can safely access its contents.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1573,7 +1573,7 @@
|
||||
Number of user columns in the relation (system columns not
|
||||
counted). There must be this many corresponding entries in
|
||||
<structname>pg_attribute</structname>. See also
|
||||
<literal>pg_attribute.attnum</literal>
|
||||
<literal>pg_attribute.attnum</literal>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1652,7 +1652,7 @@
|
||||
(<quote>frozen</>) transaction ID in this table. This is used to track
|
||||
whether the table needs to be vacuumed in order to prevent transaction
|
||||
ID wraparound or to allow <literal>pg_clog</> to be shrunk. Zero
|
||||
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table
|
||||
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1681,7 +1681,7 @@
|
||||
</table>
|
||||
|
||||
<para>
|
||||
Several of the boolean flags in <structname>pg_class</> are maintained
|
||||
Several of the Boolean flags in <structname>pg_class</> are maintained
|
||||
lazily: they are guaranteed to be true if that's the correct state, but
|
||||
may not be reset to false immediately when the condition is no longer
|
||||
true. For example, <structfield>relhasindex</> is set by
|
||||
@ -1847,7 +1847,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
This constraint is defined locally for the relation. Note that a
|
||||
constraint can be locally defined and inherited simultaneously
|
||||
constraint can be locally defined and inherited simultaneously.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -1858,7 +1858,7 @@
|
||||
<entry>
|
||||
The number of direct inheritance ancestors this constraint has.
|
||||
A constraint with
|
||||
a nonzero number of ancestors cannot be dropped nor renamed
|
||||
a nonzero number of ancestors cannot be dropped nor renamed.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2128,7 +2128,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
If false then no one can connect to this database. This is
|
||||
used to protect the <literal>template0</> database from being altered
|
||||
used to protect the <literal>template0</> database from being altered.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2138,7 +2138,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Sets maximum number of concurrent connections that can be made
|
||||
to this database. -1 means no limit
|
||||
to this database. -1 means no limit.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2162,7 +2162,7 @@
|
||||
track whether the database needs to be vacuumed in order to prevent
|
||||
transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.
|
||||
It is the minimum of the per-table
|
||||
<structname>pg_class</>.<structfield>relfrozenxid</> values
|
||||
<structname>pg_class</>.<structfield>relfrozenxid</> values.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2175,7 +2175,7 @@
|
||||
Within this database, all tables for which
|
||||
<structname>pg_class</>.<structfield>reltablespace</> is zero
|
||||
will be stored in this tablespace; in particular, all the non-shared
|
||||
system catalogs will be there
|
||||
system catalogs will be there.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2273,7 +2273,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that when an ACL entry in another catalog is NULL, it is taken
|
||||
Note that when an ACL entry in another catalog is null, it is taken
|
||||
to represent the hard-wired default privileges for its object,
|
||||
<emphasis>not</> whatever might be in <structname>pg_default_acl</>
|
||||
at the moment. <structname>pg_default_acl</> is only consulted during
|
||||
@ -2340,7 +2340,7 @@
|
||||
For a table column, this is the column number (the
|
||||
<structfield>objid</> and <structfield>classid</> refer to the
|
||||
table itself). For all other object types, this column is
|
||||
zero
|
||||
zero.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2366,7 +2366,7 @@
|
||||
For a table column, this is the column number (the
|
||||
<structfield>refobjid</> and <structfield>refclassid</> refer
|
||||
to the table itself). For all other object types, this column
|
||||
is zero
|
||||
is zero.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2515,7 +2515,7 @@
|
||||
For a comment on a table column, this is the column number (the
|
||||
<structfield>objoid</> and <structfield>classoid</> refer to
|
||||
the table itself). For all other object types, this column is
|
||||
zero
|
||||
zero.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2743,7 +2743,7 @@
|
||||
<entry><type>text[]</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Foreign server specific options, as <quote>keyword=value</> strings.
|
||||
Foreign server specific options, as <quote>keyword=value</> strings
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -2840,7 +2840,7 @@
|
||||
index is possibly incomplete: it must still be modified by
|
||||
<command>INSERT</>/<command>UPDATE</> operations, but it cannot safely
|
||||
be used for queries. If it is unique, the uniqueness property is not
|
||||
true either
|
||||
true either.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2850,7 +2850,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
If true, queries must not use the index until the <structfield>xmin</>
|
||||
of this <structname>pg_index</> row is below their TransactionXmin
|
||||
of this <structname>pg_index</> row is below their <symbol>TransactionXmin</symbol>
|
||||
event horizon, because the table may contain broken HOT chains with
|
||||
incompatible rows that they can see
|
||||
</entry>
|
||||
@ -2863,7 +2863,7 @@
|
||||
<entry>
|
||||
If true, the index is currently ready for inserts. False means the
|
||||
index must be ignored by <command>INSERT</>/<command>UPDATE</>
|
||||
operations
|
||||
operations.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2877,7 +2877,7 @@
|
||||
of <literal>1 3</literal> would mean that the first and the third table
|
||||
columns make up the index key. A zero in this array indicates that the
|
||||
corresponding index attribute is an expression over the table columns,
|
||||
rather than a simple column reference
|
||||
rather than a simple column reference.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2888,7 +2888,7 @@
|
||||
<entry>
|
||||
For each column in the index key, this contains the OID of
|
||||
the operator class to use. See
|
||||
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link> for details
|
||||
<link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link> for details.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2899,7 +2899,7 @@
|
||||
<entry>
|
||||
This is an array of <structfield>indnatts</structfield> values that
|
||||
store per-column flag bits. The meaning of the bits is defined by
|
||||
the index's access method
|
||||
the index's access method.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -2907,18 +2907,24 @@
|
||||
<entry><structfield>indexprs</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Expression trees (in <function>nodeToString()</function> representation)
|
||||
for index attributes that are not simple column references. This is a
|
||||
list with one element for each zero entry in <structfield>indkey</>.
|
||||
NULL if all index attributes are simple references</entry>
|
||||
<entry>
|
||||
Expression trees (in <function>nodeToString()</function>
|
||||
representation) for index attributes that are not simple column
|
||||
references. This is a list with one element for each zero
|
||||
entry in <structfield>indkey</>. Null if all index attributes
|
||||
are simple references.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structfield>indpred</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Expression tree (in <function>nodeToString()</function> representation)
|
||||
for partial index predicate. NULL if not a partial index</entry>
|
||||
<entry>
|
||||
Expression tree (in <function>nodeToString()</function>
|
||||
representation) for partial index predicate. Null if not a
|
||||
partial index.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -2980,7 +2986,7 @@
|
||||
<entry>
|
||||
If there is more than one direct parent for a child table (multiple
|
||||
inheritance), this number tells the order in which the
|
||||
inherited columns are to be arranged. The count starts at 1
|
||||
inherited columns are to be arranged. The count starts at 1.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -3041,7 +3047,7 @@
|
||||
<acronym>SQL</acronym>) and true for user-defined languages.
|
||||
Currently, <application>pg_dump</application> still uses this
|
||||
to determine which languages need to be dumped, but this might be
|
||||
replaced by a different mechanism in the future
|
||||
replaced by a different mechanism in the future.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3053,7 +3059,7 @@
|
||||
True if this is a trusted language, which means that it is believed
|
||||
not to grant access to anything outside the normal SQL execution
|
||||
environment. Only superusers can create functions in untrusted
|
||||
languages
|
||||
languages.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3077,7 +3083,7 @@
|
||||
This references a function that is responsible for executing
|
||||
<quote>inline</> anonymous code blocks
|
||||
(<xref linkend="sql-do"> blocks).
|
||||
Zero if inline blocks are not supported
|
||||
Zero if inline blocks are not supported.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3088,7 +3094,7 @@
|
||||
<entry>
|
||||
This references a language validator function that is responsible
|
||||
for checking the syntax and validity of new functions when they
|
||||
are created. Zero if no validator is provided
|
||||
are created. Zero if no validator is provided.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3133,7 +3139,7 @@
|
||||
<structname>pg_largeobject</structname> was publicly readable and could be
|
||||
used to obtain the OIDs (and contents) of all large objects in the system.
|
||||
This is no longer the case; use
|
||||
<link linkend="catalog-pg-largeobject-metadata">pg_largeobject_metadata</link>
|
||||
<link linkend="catalog-pg-largeobject-metadata"><structname>pg_largeobject_metadata</></link>
|
||||
to obtain a list of large object OIDs.
|
||||
</para>
|
||||
|
||||
@ -3172,7 +3178,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Actual data stored in the large object.
|
||||
This will never be more than <symbol>LOBLKSIZE</> bytes and might be less
|
||||
This will never be more than <symbol>LOBLKSIZE</> bytes and might be less.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -3201,7 +3207,7 @@
|
||||
The catalog <structname>pg_largeobject_metadata</structname>
|
||||
holds metadata associated with large objects. The actual large object
|
||||
data is stored in
|
||||
<link linkend="catalog-pg-largeobject">pg_largeobject</link>.
|
||||
<link linkend="catalog-pg-largeobject"><structname>pg_largeobject</></link>.
|
||||
</para>
|
||||
|
||||
<table>
|
||||
@ -3222,7 +3228,7 @@
|
||||
<entry><structfield>lomowner</structfield></entry>
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-authid"><structname>pg_authid</structname></link>.oid</literal></entry>
|
||||
<entry>Owner of the largeobject</entry>
|
||||
<entry>Owner of the large object</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -3693,13 +3699,13 @@
|
||||
<row>
|
||||
<entry><structfield>tmplinline</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Name of anonymous-block handler function, or NULL if none</entry>
|
||||
<entry>Name of anonymous-block handler function, or null if none</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry><structfield>tmplvalidator</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Name of validator function, or NULL if none</entry>
|
||||
<entry>Name of validator function, or null if none</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -3853,7 +3859,7 @@
|
||||
Function returns null if any call argument is null. In that
|
||||
case the function won't actually be called at all. Functions
|
||||
that are not <quote>strict</quote> must be prepared to handle
|
||||
null inputs
|
||||
null inputs.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3913,7 +3919,7 @@
|
||||
An array with the data types of the function arguments. This includes
|
||||
only input arguments (including <literal>INOUT</literal> and
|
||||
<literal>VARIADIC</> arguments), and thus represents
|
||||
the call signature of the function
|
||||
the call signature of the function.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3927,7 +3933,7 @@
|
||||
<literal>INOUT</literal> arguments); however, if all the
|
||||
arguments are <literal>IN</literal> arguments, this field will be null.
|
||||
Note that subscripting is 1-based, whereas for historical reasons
|
||||
<structfield>proargtypes</> is subscripted from 0
|
||||
<structfield>proargtypes</> is subscripted from 0.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3945,7 +3951,7 @@
|
||||
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</>
|
||||
<structfield>proallargtypes</> not <structfield>proargtypes</>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3958,7 +3964,7 @@
|
||||
Arguments without a name are set to empty strings in the array.
|
||||
If none of the arguments have a name, this field will be null.
|
||||
Note that subscripts correspond to positions of
|
||||
<structfield>proallargtypes</> not <structfield>proargtypes</>
|
||||
<structfield>proallargtypes</> not <structfield>proargtypes</>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3972,7 +3978,7 @@
|
||||
<structfield>pronargdefaults</> elements, corresponding to the last
|
||||
<replaceable>N</> <emphasis>input</> arguments (i.e., the last
|
||||
<replaceable>N</> <structfield>proargtypes</> positions).
|
||||
If none of the arguments have defaults, this field will be null
|
||||
If none of the arguments have defaults, this field will be null.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3984,7 +3990,7 @@
|
||||
This tells the function handler how to invoke the function. It
|
||||
might be the actual source code of the function for interpreted
|
||||
languages, a link symbol, a file name, or just about anything
|
||||
else, depending on the implementation language/call convention
|
||||
else, depending on the implementation language/call convention.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -3994,7 +4000,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Additional information about how to invoke the function.
|
||||
Again, the interpretation is language-specific
|
||||
Again, the interpretation is language-specific.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -4276,7 +4282,7 @@
|
||||
<entry>
|
||||
For a table column, this is the column number (the
|
||||
<structfield>objid</> and <structfield>classid</> refer to the
|
||||
table itself). For all other object types, this column is zero
|
||||
table itself). For all other object types, this column is zero.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -4548,7 +4554,7 @@
|
||||
of rows in the table; for example, a column in which values appear about
|
||||
twice on the average could be represented by
|
||||
<structfield>stadistinct</> = -0.5.
|
||||
A zero value means the number of distinct values is unknown
|
||||
A zero value means the number of distinct values is unknown.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -4559,7 +4565,7 @@
|
||||
<entry>
|
||||
A code number indicating the kind of statistics stored in the
|
||||
<replaceable>N</>th <quote>slot</quote> of the
|
||||
<structname>pg_statistic</structname> row
|
||||
<structname>pg_statistic</structname> row.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -4571,7 +4577,7 @@
|
||||
An operator used to derive the statistics stored in the
|
||||
<replaceable>N</>th <quote>slot</quote>. For example, a
|
||||
histogram slot would show the <literal><</literal> operator
|
||||
that defines the sort order of the data
|
||||
that defines the sort order of the data.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -4581,7 +4587,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Numerical statistics of the appropriate kind for the
|
||||
<replaceable>N</>th <quote>slot</quote>, or NULL if the slot
|
||||
<replaceable>N</>th <quote>slot</quote>, or null if the slot
|
||||
kind does not involve numerical values
|
||||
</entry>
|
||||
</row>
|
||||
@ -4592,11 +4598,11 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Column data values of the appropriate kind for the
|
||||
<replaceable>N</>th <quote>slot</quote>, or NULL if the slot
|
||||
<replaceable>N</>th <quote>slot</quote>, or null if the slot
|
||||
kind does not store any data values. Each array's element
|
||||
values are actually of the specific column's data type, so there
|
||||
is no way to define these columns' type more specifically than
|
||||
<type>anyarray</>
|
||||
<type>anyarray</>.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -4810,7 +4816,7 @@
|
||||
<entry><structfield>tgattr</structfield></entry>
|
||||
<entry><type>int2vector</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.attnum</literal></entry>
|
||||
<entry>column numbers, if trigger is column-specific; otherwise an
|
||||
<entry>Column numbers, if trigger is column-specific; otherwise an
|
||||
empty array</entry>
|
||||
</row>
|
||||
|
||||
@ -4826,7 +4832,7 @@
|
||||
<entry><type>text</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Expression tree (in <function>nodeToString()</function>
|
||||
representation) for the trigger's <literal>WHEN</> condition, or NULL
|
||||
representation) for the trigger's <literal>WHEN</> condition, or null
|
||||
if none</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -5319,7 +5325,7 @@
|
||||
where Datum is 8 bytes).
|
||||
Variable-length types are always passed by reference. Note that
|
||||
<structfield>typbyval</structfield> can be false even if the
|
||||
length would allow pass-by-value
|
||||
length would allow pass-by-value.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5335,7 +5341,7 @@
|
||||
<literal>e</literal> for an enum type,
|
||||
or <literal>p</literal> for a pseudo-type.
|
||||
See also <structfield>typrelid</structfield> and
|
||||
<structfield>typbasetype</structfield>
|
||||
<structfield>typbasetype</structfield>.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5347,7 +5353,7 @@
|
||||
<structfield>typcategory</structfield> is an arbitrary classification
|
||||
of data types that is used by the parser to determine which implicit
|
||||
casts should be <quote>preferred</>.
|
||||
See <xref linkend="catalog-typcategory-table">
|
||||
See <xref linkend="catalog-typcategory-table">.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5369,7 +5375,7 @@
|
||||
True if the type is defined, false if this is a placeholder
|
||||
entry for a not-yet-defined type. When
|
||||
<structfield>typisdefined</structfield> is false, nothing
|
||||
except the type name, namespace, and OID can be relied on
|
||||
except the type name, namespace, and OID can be relied on.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5380,7 +5386,7 @@
|
||||
<entry>
|
||||
Character that separates two values of this type when parsing
|
||||
array input. Note that the delimiter is associated with the array
|
||||
element data type, not the array data type
|
||||
element data type, not the array data type.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5396,7 +5402,7 @@
|
||||
<structname>pg_class</structname> entry doesn't really represent
|
||||
a table, but it is needed anyway for the type's
|
||||
<structname>pg_attribute</structname> entries to link to.)
|
||||
Zero for non-composite types
|
||||
Zero for non-composite types.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5418,7 +5424,7 @@
|
||||
its internal representation must be some number of values of the
|
||||
<structfield>typelem</structfield> data type with no other data.
|
||||
Variable-length array types have a header defined by the array
|
||||
subroutines
|
||||
subroutines.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -5479,7 +5485,7 @@
|
||||
<entry><structfield>typanalyze</structfield></entry>
|
||||
<entry><type>regproc</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-proc"><structname>pg_proc</structname></link>.oid</literal></entry>
|
||||
<entry>Custom ANALYZE function, or 0 to use the standard function</entry>
|
||||
<entry>Custom <command>ANALYZE</command> function, or 0 to use the standard function</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -5565,7 +5571,7 @@
|
||||
<entry></entry>
|
||||
<entry><para>
|
||||
<structfield>typnotnull</structfield> represents a not-null
|
||||
constraint on a type. Used for domains only
|
||||
constraint on a type. Used for domains only.
|
||||
</para></entry>
|
||||
</row>
|
||||
|
||||
@ -5576,7 +5582,7 @@
|
||||
<entry><para>
|
||||
If this is a domain (see <structfield>typtype</structfield>), then
|
||||
<structfield>typbasetype</structfield> identifies the type that this
|
||||
one is based on. Zero if this type is not a domain
|
||||
one is based on. Zero if this type is not a domain.
|
||||
</para></entry>
|
||||
</row>
|
||||
|
||||
@ -5587,7 +5593,7 @@
|
||||
<entry><para>
|
||||
Domains use <structfield>typtypmod</structfield> to record the <literal>typmod</>
|
||||
to be applied to their base type (-1 if base type does not use a
|
||||
<literal>typmod</>). -1 if this type is not a domain
|
||||
<literal>typmod</>). -1 if this type is not a domain.
|
||||
</para></entry>
|
||||
</row>
|
||||
|
||||
@ -5600,7 +5606,7 @@
|
||||
for a domain that is an array (that is, <structfield>typbasetype</> is
|
||||
an array type; the domain's <structfield>typelem</> will match the base
|
||||
type's <structfield>typelem</structfield>).
|
||||
Zero for types other than domains over array types
|
||||
Zero for types other than domains over array types.
|
||||
</para></entry>
|
||||
</row>
|
||||
|
||||
@ -5611,7 +5617,7 @@
|
||||
<entry><para>
|
||||
If <structfield>typdefaultbin</> is not null, it is the <function>nodeToString()</function>
|
||||
representation of a default expression for the type. This is
|
||||
only used for domains
|
||||
only used for domains.
|
||||
</para></entry>
|
||||
</row>
|
||||
|
||||
@ -5627,7 +5633,7 @@
|
||||
<structfield>typdefaultbin</> is null and <structfield>typdefault</> is
|
||||
not, then <structfield>typdefault</> is the external representation of
|
||||
the type's default value, which might be fed to the type's input
|
||||
converter to produce a constant
|
||||
converter to produce a constant.
|
||||
</para></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -5766,7 +5772,7 @@
|
||||
<entry><type>text[]</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
User mapping specific options, as <quote>keyword=value</> strings.
|
||||
User mapping specific options, as <quote>keyword=value</> strings
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -6126,7 +6132,7 @@
|
||||
<entry><structfield>tablespace</structfield></entry>
|
||||
<entry><type>name</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.spcname</literal></entry>
|
||||
<entry>Name of tablespace containing index (NULL if default for database)</entry>
|
||||
<entry>Name of tablespace containing index (null if default for database)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>indexdef</structfield></entry>
|
||||
@ -6193,7 +6199,7 @@
|
||||
<entry><type>text</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
type of the lockable object:
|
||||
Type of the lockable object:
|
||||
<literal>relation</>,
|
||||
<literal>extend</>,
|
||||
<literal>page</>,
|
||||
@ -6212,7 +6218,7 @@
|
||||
<entry>
|
||||
OID of the database in which the object exists, or
|
||||
zero if the object is a shared object, or
|
||||
NULL if the object is a transaction ID
|
||||
null if the object is a transaction ID
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6220,7 +6226,7 @@
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
OID of the relation, or NULL if the object is not
|
||||
OID of the relation, or null if the object is not
|
||||
a relation or part of a relation
|
||||
</entry>
|
||||
</row>
|
||||
@ -6229,7 +6235,7 @@
|
||||
<entry><type>integer</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Page number within the relation, or NULL if the object
|
||||
Page number within the relation, or null if the object
|
||||
is not a tuple or relation page
|
||||
</entry>
|
||||
</row>
|
||||
@ -6238,7 +6244,7 @@
|
||||
<entry><type>smallint</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Tuple number within the page, or NULL if the object is not a tuple
|
||||
Tuple number within the page, or null if the object is not a tuple
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6246,7 +6252,7 @@
|
||||
<entry><type>text</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Virtual ID of a transaction, or NULL if the object is not a
|
||||
Virtual ID of a transaction, or null if the object is not a
|
||||
virtual transaction ID
|
||||
</entry>
|
||||
</row>
|
||||
@ -6255,7 +6261,7 @@
|
||||
<entry><type>xid</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
ID of a transaction, or NULL if the object is not a transaction ID
|
||||
ID of a transaction, or null if the object is not a transaction ID
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6263,7 +6269,7 @@
|
||||
<entry><type>oid</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.oid</literal></entry>
|
||||
<entry>
|
||||
OID of the system catalog containing the object, or NULL if the
|
||||
OID of the system catalog containing the object, or null if the
|
||||
object is not a general database object
|
||||
</entry>
|
||||
</row>
|
||||
@ -6272,7 +6278,7 @@
|
||||
<entry><type>oid</type></entry>
|
||||
<entry>any OID column</entry>
|
||||
<entry>
|
||||
OID of the object within its system catalog, or NULL if the
|
||||
OID of the object within its system catalog, or null if the
|
||||
object is not a general database object.
|
||||
For advisory locks it is used to distinguish the two key
|
||||
spaces (<literal>1</> for an int8 key, <literal>2</> for two
|
||||
@ -6287,7 +6293,7 @@
|
||||
For a table column, this is the column number (the
|
||||
<structfield>classid</> and <structfield>objid</> refer to the
|
||||
table itself). For all other object types, this column is
|
||||
zero. NULL if the object is not a general database object
|
||||
zero. Null if the object is not a general database object
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6304,7 +6310,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
Process ID of the server process holding or awaiting this
|
||||
lock. NULL if the lock is held by a prepared transaction
|
||||
lock. Null if the lock is held by a prepared transaction.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6452,7 +6458,7 @@
|
||||
this is the <command>PREPARE</command> statement submitted by
|
||||
the client. For prepared statements created via the
|
||||
frontend/backend protocol, this is the text of the prepared
|
||||
statement itself
|
||||
statement itself.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6469,7 +6475,7 @@
|
||||
The expected parameter types for the prepared statement in the
|
||||
form of an array of <type>regtype</type>. The OID corresponding
|
||||
to an element of this array can be obtained by casting the
|
||||
<type>regtype</type> value to <type>oid</type>
|
||||
<type>regtype</type> value to <type>oid</type>.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6675,7 +6681,7 @@
|
||||
<entry></entry>
|
||||
<entry>
|
||||
For roles that can log in, this sets maximum number of concurrent
|
||||
connections this role can make. -1 means no limit
|
||||
connections this role can make. -1 means no limit.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -6691,7 +6697,7 @@
|
||||
<entry><type>timestamptz</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Password expiry time (only used for password authentication);
|
||||
NULL if no expiration</entry>
|
||||
null if no expiration</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
@ -6845,19 +6851,19 @@
|
||||
<row>
|
||||
<entry><structfield>min_val</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Minimum allowed value of the parameter (NULL for non-numeric
|
||||
<entry>Minimum allowed value of the parameter (null for non-numeric
|
||||
values)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>max_val</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Maximum allowed value of the parameter (NULL for non-numeric
|
||||
<entry>Maximum allowed value of the parameter (null for non-numeric
|
||||
values)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>enumvals</structfield></entry>
|
||||
<entry><type>text[]</type></entry>
|
||||
<entry>Allowed values of an enum parameter (NULL for non-enum
|
||||
<entry>Allowed values of an enum parameter (null for non-enum
|
||||
values)</entry>
|
||||
</row>
|
||||
<row>
|
||||
@ -6875,16 +6881,16 @@
|
||||
<row>
|
||||
<entry><structfield>sourcefile</structfield></entry>
|
||||
<entry><type>text</type></entry>
|
||||
<entry>Configuration file the current value was set in (NULL for
|
||||
<entry>Configuration file the current value was set in (null for
|
||||
values set from sources other than configuration files, or when
|
||||
examined by a non-superuser).
|
||||
Helpful when using configuration include directives</entry>
|
||||
examined by a non-superuser);
|
||||
helpful when using <literal>include</> directives in configuration files</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>sourceline</structfield></entry>
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>Line number within the configuration file the current value was
|
||||
set at (NULL for values set from sources other than configuration files,
|
||||
set at (null for values set from sources other than configuration files,
|
||||
or when examined by a non-superuser)
|
||||
</entry>
|
||||
</row>
|
||||
@ -7101,7 +7107,7 @@
|
||||
likely to increase as the table grows; the positive form is used when
|
||||
the column seems to have a fixed number of possible values.) For
|
||||
example, -1 indicates a unique column in which the number of distinct
|
||||
values is the same as the number of rows
|
||||
values is the same as the number of rows.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
@ -7110,9 +7116,9 @@
|
||||
<entry><type>anyarray</type></entry>
|
||||
<entry></entry>
|
||||
<entry>
|
||||
A list of the most common values in the column. (NULL if
|
||||
A list of the most common values in the column. (Null if
|
||||
no values seem to be more common than any others.)
|
||||
For some datatypes such as <type>tsvector</>, this is a list of
|
||||
For some data types such as <type>tsvector</>, this is a list of
|
||||
the most common element values rather than values of the type itself.
|
||||
</entry>
|
||||
</row>
|
||||
@ -7124,8 +7130,8 @@
|
||||
<entry>
|
||||
A list of the frequencies of the most common values or elements,
|
||||
i.e., number of occurrences of each divided by total number of rows.
|
||||
(NULL when <structfield>most_common_vals</structfield> is.)
|
||||
For some datatypes such as <type>tsvector</>, it can also store some
|
||||
(Null when <structfield>most_common_vals</structfield> is.)
|
||||
For some data types such as <type>tsvector</>, it can also store some
|
||||
additional information, making it longer than the
|
||||
<structfield>most_common_vals</> array.
|
||||
</entry>
|
||||
@ -7139,7 +7145,7 @@
|
||||
A list of values that divide the column's values into groups of
|
||||
approximately equal population. The values in
|
||||
<structfield>most_common_vals</>, if present, are omitted from this
|
||||
histogram calculation. (This column is NULL if the column data type
|
||||
histogram calculation. (This column is null if the column data type
|
||||
does not have a <literal><</> operator or if the
|
||||
<structfield>most_common_vals</> list accounts for the entire
|
||||
population.)
|
||||
@ -7155,7 +7161,7 @@
|
||||
logical ordering of the column values. This ranges from -1 to +1.
|
||||
When the value is near -1 or +1, an index scan on the column will
|
||||
be estimated to be cheaper than when it is near zero, due to reduction
|
||||
of random access to the disk. (This column is NULL if the column data
|
||||
of random access to the disk. (This column is null if the column data
|
||||
type does not have a <literal><</> operator.)
|
||||
</entry>
|
||||
</row>
|
||||
@ -7220,25 +7226,25 @@
|
||||
<entry><structfield>tablespace</structfield></entry>
|
||||
<entry><type>name</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-tablespace"><structname>pg_tablespace</structname></link>.spcname</literal></entry>
|
||||
<entry>Name of tablespace containing table (NULL if default for database)</entry>
|
||||
<entry>Name of tablespace containing table (null if default for database)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>hasindexes</structfield></entry>
|
||||
<entry><type>boolean</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhasindex</literal></entry>
|
||||
<entry>true if table has (or recently had) any indexes</entry>
|
||||
<entry>True if table has (or recently had) any indexes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>hasrules</structfield></entry>
|
||||
<entry><type>boolean</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhasrules</literal></entry>
|
||||
<entry>true if table has (or once had) rules</entry>
|
||||
<entry>True if table has (or once had) rules</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><structfield>hastriggers</structfield></entry>
|
||||
<entry><type>boolean</type></entry>
|
||||
<entry><literal><link linkend="catalog-pg-class"><structname>pg_class</structname></link>.relhastriggers</literal></entry>
|
||||
<entry>true if table has (or once had) triggers</entry>
|
||||
<entry>True if table has (or once had) triggers</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
@ -7509,7 +7515,7 @@
|
||||
<entry>
|
||||
User mapping specific options, as <quote>keyword=value</>
|
||||
strings, if the current user is the owner of the foreign
|
||||
server, else null.
|
||||
server, else null
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/chkpass.sgml,v 1.2 2007/12/06 04:12:09 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/chkpass.sgml,v 1.3 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="chkpass">
|
||||
<title>chkpass</title>
|
||||
@ -32,7 +32,7 @@
|
||||
passwords without re-encrypting them. If you want the encrypted password
|
||||
without the colon then use the <function>raw()</> function.
|
||||
This allows you to use the
|
||||
type with things like Apache's Auth_PostgreSQL module.
|
||||
type with things like Apache's <literal>Auth_PostgreSQL</> module.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -43,7 +43,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that the chkpass data type is not indexable.
|
||||
Note that the <type>chkpass</type> data type is not indexable.
|
||||
<!--
|
||||
I haven't worried about making this type indexable. I doubt that anyone
|
||||
would ever need to sort a file in order of encrypted password.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.6 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="citext">
|
||||
<title>citext</title>
|
||||
@ -62,7 +62,7 @@ SELECT * FROM tab WHERE lower(col) = LOWER(?);
|
||||
lower case characters is dependent on the rules of
|
||||
the <literal>LC_CTYPE</> locale setting. Again, this behavior is
|
||||
identical to the use of <function>lower</> in queries. But because it's
|
||||
done transparently by the datatype, you don't have to remember to do
|
||||
done transparently by the data type, you don't have to remember to do
|
||||
anything special in your queries.
|
||||
</para>
|
||||
|
||||
@ -90,8 +90,8 @@ SELECT * FROM users WHERE nick = 'Larry';
|
||||
</programlisting>
|
||||
|
||||
The <command>SELECT</> statement will return one tuple, even though
|
||||
the <structfield>nick</> column was set to <quote>larry</> and the query
|
||||
was for <quote>Larry</>.
|
||||
the <structfield>nick</> column was set to <literal>larry</> and the query
|
||||
was for <literal>Larry</>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
@ -184,7 +184,7 @@ SELECT * FROM users WHERE nick = 'Larry';
|
||||
<listitem>
|
||||
<para>
|
||||
<type>citext</> is not as efficient as <type>text</> because the
|
||||
operator functions and the btree comparison functions must make copies
|
||||
operator functions and the B-tree comparison functions must make copies
|
||||
of the data and convert it to lower case for comparisons. It is,
|
||||
however, slightly more efficient than using <function>lower</> to get
|
||||
case-insensitive matching.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.140 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.141 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
<title>Client Authentication</title>
|
||||
@ -80,7 +80,7 @@
|
||||
A record is made
|
||||
up of a number of fields which are separated by spaces and/or tabs.
|
||||
Fields can contain white space if the field value is quoted.
|
||||
Quoting one of the keywords in a database or username field (e.g.,
|
||||
Quoting one of the keywords in a database or user name field (e.g.,
|
||||
<literal>all</> or <literal>replication</>) makes the word lose its special
|
||||
character, and just match a database or user with that name.
|
||||
</para>
|
||||
@ -578,10 +578,10 @@ local db1,db2,@demodbs all md5
|
||||
</sect1>
|
||||
|
||||
<sect1 id="auth-username-maps">
|
||||
<title>Username maps</title>
|
||||
<title>User name maps</title>
|
||||
|
||||
<indexterm zone="auth-username-maps">
|
||||
<primary>Username maps</primary>
|
||||
<primary>User name maps</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
@ -589,10 +589,10 @@ local db1,db2,@demodbs all md5
|
||||
the name of the operating system user that initiated the connection
|
||||
might not be the same as the database user he needs to connect as.
|
||||
In this case, a user name map can be applied to map the operating system
|
||||
username to a database user. To use username mapping, specify
|
||||
user name to a database user. To use user name mapping, specify
|
||||
<literal>map</literal>=<replaceable>map-name</replaceable>
|
||||
in the options field in <filename>pg_hba.conf</filename>. This option is
|
||||
supported for all authentication methods that receive external usernames.
|
||||
supported for all authentication methods that receive external user names.
|
||||
Since different mappings might be needed for different connections,
|
||||
the name of the map to be used is specified in the
|
||||
<replaceable>map-name</replaceable> parameter in <filename>pg_hba.conf</filename>
|
||||
@ -600,7 +600,7 @@ local db1,db2,@demodbs all md5
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Username maps are defined in the ident map file, which by default is named
|
||||
User name maps are defined in the ident map file, which by default is named
|
||||
<filename>pg_ident.conf</><indexterm><primary>pg_ident.conf</primary></indexterm>
|
||||
and is stored in the
|
||||
cluster's data directory. (It is possible to place the map file
|
||||
@ -636,13 +636,13 @@ local db1,db2,@demodbs all md5
|
||||
expression can include a single capture, or parenthesized subexpression,
|
||||
which can then be referenced in the <replaceable>database-username</>
|
||||
field as <literal>\1</> (backslash-one). This allows the mapping of
|
||||
multiple usernames in a single line, which is particularly useful for
|
||||
multiple user names in a single line, which is particularly useful for
|
||||
simple syntax substitutions. For example, these entries
|
||||
<programlisting>
|
||||
mymap /^(.*)@mydomain\.com$ \1
|
||||
mymap /^(.*)@otherdomain\.com$ guest
|
||||
</programlisting>
|
||||
will remove the domain part for users with system usernames that end with
|
||||
will remove the domain part for users with system user names that end with
|
||||
<literal>@mydomain.com</>, and allow any user whose system name ends with
|
||||
<literal>@otherdomain.com</> to log in as <literal>guest</>.
|
||||
</para>
|
||||
@ -652,7 +652,7 @@ mymap /^(.*)@otherdomain\.com$ guest
|
||||
Keep in mind that by default, a regular expression can match just part of
|
||||
a string. It's usually wise to use <literal>^</> and <literal>$</>, as
|
||||
shown in the above example, to force the match to be to the entire
|
||||
system username.
|
||||
system user name.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
@ -835,7 +835,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -845,10 +845,10 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details. For a Kerberos
|
||||
principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
|
||||
username used for mapping is <literal>username/hostbased</literal>
|
||||
user name used for mapping is <literal>username/hostbased</literal>
|
||||
if <literal>include_realm</literal> is disabled, and
|
||||
<literal>username/hostbased@EXAMPLE.COM</literal> if
|
||||
<literal>include_realm</literal> is enabled.
|
||||
@ -862,7 +862,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -906,7 +906,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -916,7 +916,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -928,7 +928,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1006,13 +1006,13 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Client principals must have their <productname>PostgreSQL</> database user
|
||||
name as their first component, for example
|
||||
<literal>pgusername@realm</>. Alternatively, you can use a username
|
||||
<literal>pgusername@realm</>. Alternatively, you can use a user name
|
||||
mapping to map from the first component of the principal name to the
|
||||
database user name. By default, the realm of the client is
|
||||
not checked by <productname>PostgreSQL</>. If you have cross-realm
|
||||
authentication enabled and need to verify the realm, use the
|
||||
<literal>krb_realm</> parameter, or enable <literal>include_realm</>
|
||||
and use username mapping to check the realm.
|
||||
and use user name mapping to check the realm.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1041,7 +1041,7 @@ omicron bryanh guest1
|
||||
principal matching the requested database user name. For example, for
|
||||
database user name <literal>fred</>, principal
|
||||
<literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
|
||||
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
|
||||
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a user name
|
||||
map, as described in <xref linkend="auth-username-maps">.
|
||||
</para>
|
||||
|
||||
@ -1063,7 +1063,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1075,7 +1075,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1087,7 +1087,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1119,7 +1119,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
The ident authentication method works by obtaining the client's
|
||||
operating system user name and using it as the allowed database user
|
||||
name (with an optional username mapping).
|
||||
name (with an optional user name mapping).
|
||||
The determination of the client's
|
||||
user name is the security-critical point, and it works differently
|
||||
depending on the connection type, as described below.
|
||||
@ -1132,7 +1132,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1245,7 +1245,7 @@ omicron bryanh guest1
|
||||
|
||||
<para>
|
||||
In the second mode, the server first binds to the LDAP directory with
|
||||
a fixed username and password, specified with <replaceable>ldapbinduser</>
|
||||
a fixed user name and password, specified with <replaceable>ldapbinduser</>
|
||||
and <replaceable>ldapbinddn</>, and performs a search for the user trying
|
||||
to log in to the database. If no user and password is configured, an
|
||||
anonymous bind will be attempted to the directory. The search will be
|
||||
@ -1295,7 +1295,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapprefix</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
String to prepend to the username when forming the DN to bind as,
|
||||
String to prepend to the user name when forming the DN to bind as,
|
||||
when doing simple bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1304,7 +1304,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapsuffix</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
String to append to the username when forming the DN to bind as,
|
||||
String to append to the user name when forming the DN to bind as,
|
||||
when doing simple bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1340,7 +1340,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapsearchattribute</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Attribute to match against the username in the search when doing
|
||||
Attribute to match against the user name in the search when doing
|
||||
search+bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1464,9 +1464,9 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
|
||||
the client provide a valid certificate. No password prompt will be sent
|
||||
to the client. The <literal>cn</literal> (Common Name) attribute of the
|
||||
certificate
|
||||
will be compared to the requested database username, and if they match
|
||||
the login will be allowed. Username mapping can be used to allow
|
||||
<literal>cn</literal> to be different from the database username.
|
||||
will be compared to the requested database user name, and if they match
|
||||
the login will be allowed. User name mapping can be used to allow
|
||||
<literal>cn</literal> to be different from the database user name.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1477,7 +1477,7 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.303 2010/08/03 19:02:21 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.304 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter Id="runtime-config">
|
||||
<title>Server Configuration</title>
|
||||
@ -243,7 +243,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
<listitem>
|
||||
<para>
|
||||
Specifies the configuration file for
|
||||
<xref linkend="auth-username-maps"> username mapping
|
||||
<xref linkend="auth-username-maps"> user name mapping
|
||||
(customarily called <filename>pg_ident.conf</>).
|
||||
This parameter can only be set at server start.
|
||||
</para>
|
||||
@ -1495,7 +1495,7 @@ SET ENABLE_SEQSCAN TO OFF;
|
||||
one transaction is determined by the setting in effect when it
|
||||
commits. It is therefore possible, and useful, to have some
|
||||
transactions commit synchronously and others asynchronously.
|
||||
For example, to make a single multi-statement transaction commit
|
||||
For example, to make a single multistatement transaction commit
|
||||
asynchronously when the default is the opposite, issue <command>SET
|
||||
LOCAL synchronous_commit TO OFF</> within the transaction.
|
||||
</para>
|
||||
@ -3407,9 +3407,8 @@ local0.* /var/log/postgresql
|
||||
fields to displayed messages. <literal>TERSE</> excludes
|
||||
the logging of <literal>DETAIL</>, <literal>HINT</>,
|
||||
<literal>QUERY</>, and <literal>CONTEXT</> error information.
|
||||
<literal>VERBOSE</> output includes the <link
|
||||
linkend="errcodes-appendix">SQLSTATE</> error
|
||||
code and the source code file name, function name,
|
||||
<literal>VERBOSE</> output includes the <symbol>SQLSTATE</> error
|
||||
code (see also <xref linkend="errcodes-appendix">) and the source code file name, function name,
|
||||
and line number that generated the error.
|
||||
Only superusers can change this setting.
|
||||
</para>
|
||||
@ -5492,7 +5491,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
|
||||
the server. The default value of <literal>NAMEDATALEN</> is
|
||||
64; therefore the default
|
||||
<varname>max_identifier_length</varname> is 63 bytes, which
|
||||
can be less than 63 characters when using multi-byte encodings.
|
||||
can be less than 63 characters when using multibyte encodings.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -5803,7 +5802,7 @@ plruby.use_strict = true # generates error: unknown class name
|
||||
If on, emit information about lock usage. Information dumped
|
||||
includes the type of lock operation, the type of lock and the unique
|
||||
identifier of the object being locked or unlocked. Also included
|
||||
are bitmasks for the lock types already granted on this object as
|
||||
are bit masks for the lock types already granted on this object as
|
||||
well as for the lock types awaited on this object. For each lock
|
||||
type a count of the number of granted locks and waiting locks is
|
||||
also dumped as well as the totals. An example of the log file output
|
||||
@ -5823,7 +5822,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
|
||||
wait(0) type(INVALID)
|
||||
</screen>
|
||||
Details of the structure being dumped may be found in
|
||||
src/include/storage/lock.h
|
||||
<filename>src/include/storage/lock.h</filename>.
|
||||
</para>
|
||||
<para>
|
||||
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
|
||||
@ -5917,7 +5916,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
|
||||
<listitem>
|
||||
<para>
|
||||
If set, dumps information about all current locks when a
|
||||
DeadLockTimeout occurs.
|
||||
deadlock timeout occurs.
|
||||
</para>
|
||||
<para>
|
||||
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
|
||||
@ -5935,7 +5934,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
|
||||
<listitem>
|
||||
<para>
|
||||
If set, logs system resource usage statistics (memory and CPU) on
|
||||
various btree operations.
|
||||
various B-tree operations.
|
||||
</para>
|
||||
<para>
|
||||
This parameter is only available if the <symbol>BTREE_BUILD_STATS</symbol>
|
||||
@ -5981,7 +5980,7 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
|
||||
to the log. The default is <literal>WARNING</>. Note that
|
||||
<literal>LOG</> has a different rank here than in
|
||||
<varname>client_min_messages</>.
|
||||
Parameter should be set in the postgresql.conf only.
|
||||
Parameter should be set in <filename>postgresql.conf</filename> only.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/contrib-spi.sgml,v 1.2 2007/12/06 04:12:09 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/contrib-spi.sgml,v 1.3 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="contrib-spi">
|
||||
<title>spi</title>
|
||||
@ -133,8 +133,8 @@ CREATE TABLE mytab (
|
||||
<para>
|
||||
<function>set_timetravel()</> allows you to turn time-travel on or off for
|
||||
a table.
|
||||
<literal>set_timetravel('mytab', 1)</> will turn TT ON for table mytab.
|
||||
<literal>set_timetravel('mytab', 0)</> will turn TT OFF for table mytab.
|
||||
<literal>set_timetravel('mytab', 1)</> will turn TT ON for table <literal>mytab</>.
|
||||
<literal>set_timetravel('mytab', 0)</> will turn TT OFF for table <literal>mytab</>.
|
||||
In both cases the old status is reported. While TT is off, you can modify
|
||||
the start_date and stop_date columns freely. Note that the on/off status
|
||||
is local to the current database session — fresh sessions will
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.8 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.9 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="cube">
|
||||
<title>cube</title>
|
||||
@ -9,7 +9,7 @@
|
||||
|
||||
<para>
|
||||
This module implements a data type <type>cube</> for
|
||||
representing multi-dimensional cubes.
|
||||
representing multidimensional cubes.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
@ -98,7 +98,7 @@
|
||||
<para>
|
||||
The <filename>cube</> module includes a GiST index operator class for
|
||||
<type>cube</> values.
|
||||
The operators supported by the GiST opclass are shown in <xref linkend="cube-gist-operators">.
|
||||
The operators supported by the GiST operator class are shown in <xref linkend="cube-gist-operators">.
|
||||
</para>
|
||||
|
||||
<table id="cube-gist-operators">
|
||||
@ -140,7 +140,7 @@
|
||||
respectively called <literal>@</> and <literal>~</>. These names are still available, but are
|
||||
deprecated and will eventually be retired. Notice that the old names
|
||||
are reversed from the convention formerly followed by the core geometric
|
||||
datatypes!)
|
||||
data types!)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -339,7 +339,7 @@ cube_inter
|
||||
|
||||
<para>
|
||||
In all binary operations on differently-dimensioned cubes, I assume the
|
||||
lower-dimensional one to be a cartesian projection, i. e., having zeroes
|
||||
lower-dimensional one to be a Cartesian projection, i. e., having zeroes
|
||||
in place of coordinates omitted in the string representation. The above
|
||||
examples are equivalent to:
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.52 2009/12/07 19:19:56 mha Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.53 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<appendix id="cvs">
|
||||
<appendixinfo>
|
||||
@ -35,14 +35,14 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using <productname>git</> is the most flexible way to work with the source, and it
|
||||
Using <productname>Git</> is the most flexible way to work with the source, and it
|
||||
allows you to work offline without having constant access to the project servers.
|
||||
<productname>rsync</> based <productname>cvs</> also lets you work offline, but
|
||||
lacks many of the other advantages of <productname>git</>.
|
||||
<productname>rsync</> based <productname>CVS</> also lets you work offline, but
|
||||
lacks many of the other advantages of <productname>Git</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Our Wiki, <ulink
|
||||
Our wiki, <ulink
|
||||
url="http://wiki.postgresql.org/wiki/Working_with_CVS"></ulink> and
|
||||
<ulink url="http://wiki.postgresql.org/wiki/Working_with_Git"></ulink>,
|
||||
has additional details on working with CVS and Git.
|
||||
@ -52,7 +52,7 @@
|
||||
<title>Getting The Source Via <productname>Git</></title>
|
||||
|
||||
<para>
|
||||
With <productname>git</> you will make a copy of the entire code repository
|
||||
With <productname>Git</> you will make a copy of the entire code repository
|
||||
to your local machine, so you will have access to all history and branches
|
||||
offline. This is the fastest and most flexible way to develop or test
|
||||
patches.
|
||||
@ -63,35 +63,35 @@
|
||||
|
||||
<step>
|
||||
<para>
|
||||
You will need an installed version of <productname>git</>, which you can get
|
||||
You will need an installed version of <productname>Git</>, which you can get
|
||||
from <ulink url="http://git-scm.com"></ulink>. Many systems also have a recent
|
||||
version of <application>git</> installed by default, or available in their
|
||||
version of <application>Git</> installed by default, or available in their
|
||||
package repository system.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>
|
||||
To being using the git repository, make a clone of the official mirror:
|
||||
To being using the Git repository, make a clone of the official mirror:
|
||||
|
||||
<programlisting>
|
||||
git clone git://git.postgresql.org/git/postgresql.git
|
||||
</programlisting>
|
||||
|
||||
This will copy the full repository to your local machine, so it may take
|
||||
a while to complete, especially if you have a slow internet connection.
|
||||
a while to complete, especially if you have a slow Internet connection.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The git mirror can also be reached via the http protocol in case for example
|
||||
a firewall is blocking access to the git protocol. Just replace the URL
|
||||
The Git mirror can also be reached via the HTTP protocol in case for example
|
||||
a firewall is blocking access to the Git protocol. Just replace the URL
|
||||
like:
|
||||
|
||||
<programlisting>
|
||||
git clone http://git.postgresql.org/git/postgresql.git
|
||||
</programlisting>
|
||||
|
||||
The http protocol is less efficient than the git protocol, so it will be
|
||||
The HTTP protocol is less efficient than the Git protocol, so it will be
|
||||
slightly slower to use.
|
||||
</para>
|
||||
</step>
|
||||
@ -108,7 +108,7 @@ git fetch
|
||||
</step>
|
||||
</procedure>
|
||||
<para>
|
||||
<productname>git</> can do a lot more things than just fetch the source. For
|
||||
<productname>Git</> can do a lot more things than just fetch the source. For
|
||||
more information, consult the man pages for the product, or the website at
|
||||
<ulink url="http://git-scm.com"></>.
|
||||
</para>
|
||||
@ -226,7 +226,7 @@ cvs update
|
||||
CVS repository. To work around that deficiency, use
|
||||
<productname>cvsutils</productname>, which is packaged in several
|
||||
operating systems, and is available in source form at <ulink
|
||||
url="http://www.red-bean.com/cvsutils/"></ulink>, or use <productname>git</>
|
||||
url="http://www.red-bean.com/cvsutils/"></ulink>, or use <productname>Git</>
|
||||
or another system designed to work offline.
|
||||
</para>
|
||||
|
||||
@ -265,7 +265,7 @@ rsync -avzH --delete anoncvs.postgresql.org::pgsql-cvs cvsroot/
|
||||
</programlisting>
|
||||
For full instructions, see the "rsync" section in the
|
||||
<ulink url="http://pgfoundry.org/docman/view.php/1000040/4/PGBuildFarm-HOWTO.txt">
|
||||
pgbuildfarm instructions</ulink>.
|
||||
PostgreSQL Build Farm instructions</ulink>.
|
||||
</para>
|
||||
</sect1>
|
||||
</appendix>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.256 2010/08/10 20:41:27 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.257 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="datatype">
|
||||
<title>Data Types</title>
|
||||
@ -3792,7 +3792,7 @@ SELECT to_tsvector('english', 'The Fat Rats');
|
||||
|
||||
<para>
|
||||
A <type>tsquery</type> value stores lexemes that are to be
|
||||
searched for, and combines them honoring the boolean operators
|
||||
searched for, and combines them honoring the Boolean operators
|
||||
<literal>&</literal> (AND), <literal>|</literal> (OR), and
|
||||
<literal>!</> (NOT). Parentheses can be used to enforce grouping
|
||||
of the operators:
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.14 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.15 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="dblink">
|
||||
<title>dblink</title>
|
||||
@ -413,7 +413,7 @@ SELECT *
|
||||
extension.) This allows the system to understand what
|
||||
<literal>*</> should expand to, and what <structname>proname</>
|
||||
in the <literal>WHERE</> clause refers to, in advance of trying
|
||||
to execute the function. At runtime, an error will be thrown
|
||||
to execute the function. At run time, an error will be thrown
|
||||
if the actual query result from the remote database does not
|
||||
have the same number of columns shown in the <literal>FROM</> clause.
|
||||
The column names need not match, however, and <function>dblink</>
|
||||
@ -1320,7 +1320,7 @@ dblink_get_notify(text connname) returns setof (notify_name text, be_pid int, ex
|
||||
|
||||
<refsect1>
|
||||
<title>Return Value</title>
|
||||
<para>Returns setof (notify_name text, be_pid int, extra text), or an empty set if none.</para>
|
||||
<para>Returns <type>setof (notify_name text, be_pid int, extra text)</type>, or an empty set if none.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
@ -1615,7 +1615,7 @@ dblink_get_pkey(text relname) returns setof dblink_pkey_results
|
||||
|
||||
<para>
|
||||
Returns one row for each primary key field, or no rows if the relation
|
||||
has no primary key. The result rowtype is defined as
|
||||
has no primary key. The result row type is defined as
|
||||
|
||||
<programlisting>
|
||||
CREATE TYPE dblink_pkey_results AS (position int, colname text);
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.20 2010/02/07 20:48:09 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.21 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="diskusage">
|
||||
<title>Monitoring Disk Usage</title>
|
||||
@ -52,7 +52,7 @@ SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'custom
|
||||
</programlisting>
|
||||
Each page is typically 8 kilobytes. (Remember, <structfield>relpages</>
|
||||
is only updated by <command>VACUUM</>, <command>ANALYZE</>, and
|
||||
a few DDL commands such as <command>CREATE INDEX</>.) The file pathname
|
||||
a few DDL commands such as <command>CREATE INDEX</>.) The file path name
|
||||
is of interest if you want to examine the table's disk file directly.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.85 2010/06/12 09:55:12 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.86 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<appendix id="docguide">
|
||||
<title>Documentation</title>
|
||||
@ -241,7 +241,7 @@
|
||||
<para>
|
||||
It's possible that the ports do not update the main catalog file
|
||||
in <filename>/usr/local/share/sgml/catalog.ports</filename> or order
|
||||
isn't proper . Be sure to have the following lines in begining of file:
|
||||
isn't proper . Be sure to have the following lines in beginning of file:
|
||||
<programlisting>
|
||||
CATALOG "openjade/catalog"
|
||||
CATALOG "iso8879/catalog"
|
||||
@ -306,7 +306,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 tool chain
|
||||
installed and you want to install the rest of the toolchain
|
||||
locally.)
|
||||
</para>
|
||||
</step>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/earthdistance.sgml,v 1.3 2007/12/06 04:12:10 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/earthdistance.sgml,v 1.4 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="earthdistance">
|
||||
<title>earthdistance</title>
|
||||
@ -12,7 +12,7 @@
|
||||
calculating great circle distances on the surface of the Earth. The one
|
||||
described first depends on the <filename>cube</> package (which
|
||||
<emphasis>must</> be installed before <filename>earthdistance</> can be
|
||||
installed). The second one is based on the built-in <type>point</> datatype,
|
||||
installed). The second one is based on the built-in <type>point</> data type,
|
||||
using longitude and latitude for the coordinates.
|
||||
</para>
|
||||
|
||||
@ -38,7 +38,7 @@
|
||||
The radius of the Earth is obtained from the <function>earth()</>
|
||||
function. It is given in meters. But by changing this one function you can
|
||||
change the module to use some other units, or to use a different value of
|
||||
the radius that you feel is more appropiate.
|
||||
the radius that you feel is more appropriate.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.103 2010/08/11 19:03:16 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.104 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="ecpg">
|
||||
<title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
|
||||
@ -825,7 +825,7 @@ numeric *PGTYPESnumeric_from_asc(char *str, char **endptr);
|
||||
<literal>592.49E07</literal> or
|
||||
<literal>-32.84e-4</literal>.
|
||||
If the value could be parsed successfully, a valid pointer is returned,
|
||||
else the NULL pointer. At the moment ecpg always parses the complete
|
||||
else the NULL pointer. At the moment ECPG always parses the complete
|
||||
string and so it currently does not support to store the address of the
|
||||
first invalid character in <literal>*endptr</literal>. You can safely
|
||||
set <literal>endptr</literal> to NULL.
|
||||
@ -1127,14 +1127,14 @@ date PGTYPESdate_from_timestamp(timestamp dt);
|
||||
date PGTYPESdate_from_asc(char *str, char **endptr);
|
||||
</synopsis>
|
||||
The function receives a C char* string <literal>str</> and a pointer to
|
||||
a C char* string <literal>endptr</>. At the moment ecpg always parses
|
||||
a C char* string <literal>endptr</>. At the moment ECPG always parses
|
||||
the complete string and so it currently does not support to store the
|
||||
address of the first invalid character in <literal>*endptr</literal>.
|
||||
You can safely set <literal>endptr</literal> to NULL.
|
||||
</para>
|
||||
<para>
|
||||
Note that the function always assumes MDY-formatted dates and there is
|
||||
currently no variable to change that within ecpg.
|
||||
currently no variable to change that within ECPG.
|
||||
</para>
|
||||
<para>
|
||||
<xref linkend="ecpg-pgtypesdate-from-asc-table"> shows the allowed input formats.
|
||||
@ -1401,8 +1401,8 @@ int PGTYPESdate_fmt_asc(date dDate, char *fmtstring, char *outbuf);
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>fmt</entry>
|
||||
<entry>result</entry>
|
||||
<entry>Format</entry>
|
||||
<entry>Result</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
@ -1464,7 +1464,7 @@ int PGTYPESdate_fmt_asc(date dDate, char *fmtstring, char *outbuf);
|
||||
<term><function>PGTYPESdate_defmt_asc</function></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Use a format mask to convert a C char* string to a value of type
|
||||
Use a format mask to convert a C <type>char*</type> string to a value of type
|
||||
date.
|
||||
<synopsis>
|
||||
int PGTYPESdate_defmt_asc(date *d, char *fmt, char *str);
|
||||
@ -1491,9 +1491,9 @@ int PGTYPESdate_defmt_asc(date *d, char *fmt, char *str);
|
||||
<tgroup cols="3">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>fmt</entry>
|
||||
<entry>str</entry>
|
||||
<entry>result</entry>
|
||||
<entry>Format</entry>
|
||||
<entry>String</entry>
|
||||
<entry>Result</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
@ -1592,21 +1592,21 @@ timestamp PGTYPEStimestamp_from_asc(char *str, char **endptr);
|
||||
</synopsis>
|
||||
The function receives the string to parse (<literal>str</>) and a
|
||||
pointer to a C char* (<literal>endptr</>).
|
||||
At the moment ecpg always parses
|
||||
At the moment ECPG always parses
|
||||
the complete string and so it currently does not support to store the
|
||||
address of the first invalid character in <literal>*endptr</literal>.
|
||||
You can safely set <literal>endptr</literal> to NULL.
|
||||
</para>
|
||||
<para>
|
||||
The function returns the parsed timestamp on success. On error,
|
||||
<literal>PGTYPESInvalidTimestamp</literal> is returned and errno is
|
||||
<literal>PGTYPESInvalidTimestamp</literal> is returned and <varname>errno</> is
|
||||
set to <literal>PGTYPES_TS_BAD_TIMESTAMP</>. See <xref linkend="PGTYPESInvalidTimestamp"> for important notes on this value.
|
||||
|
||||
</para>
|
||||
<para>
|
||||
In general, the input string can contain any combination of an allowed
|
||||
date specification, a whitespace character and an allowed time
|
||||
specification. Note that timezones are not supported by ecpg. It can
|
||||
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
|
||||
specifiers are silently discarded.
|
||||
@ -2146,7 +2146,7 @@ interval *PGTYPESinterval_from_asc(char *str, char **endptr);
|
||||
</synopsis>
|
||||
The function parses the input string <literal>str</> and returns a
|
||||
pointer to an allocated interval variable.
|
||||
At the moment ecpg always parses
|
||||
At the moment ECPG always parses
|
||||
the complete string and so it currently does not support to store the
|
||||
address of the first invalid character in <literal>*endptr</literal>.
|
||||
You can safely set <literal>endptr</literal> to NULL.
|
||||
@ -2195,7 +2195,7 @@ int PGTYPESinterval_copy(interval *intvlsrc, interval *intvldest);
|
||||
a maximal precision of 30 significant digits. In contrast to the numeric
|
||||
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
|
||||
<function>PGTYPESdecimal_new()</> and <function>PGTYPESdecimal_free()</>. There are a lot of other
|
||||
functions that deal with the decimal type in the <productname>Informix</productname> compatibility
|
||||
mode described in <xref linkend="ecpg-informix-compat">.
|
||||
</para>
|
||||
@ -2231,7 +2231,7 @@ void PGTYPESdecimal_free(decimal *var);
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>errno values of pgtypeslib </title>
|
||||
<title>errno values of pgtypeslib</title>
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -2351,7 +2351,7 @@ void PGTYPESdecimal_free(decimal *var);
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Special constants of pgtypeslib </title>
|
||||
<title>Special constants of pgtypeslib</title>
|
||||
<para>
|
||||
<variablelist>
|
||||
<varlistentry id="PGTYPESInvalidTimestamp">
|
||||
@ -2361,7 +2361,7 @@ void PGTYPESdecimal_free(decimal *var);
|
||||
A value of type timestamp representing an invalid time stamp. This is
|
||||
returned by the function <function>PGTYPEStimestamp_from_asc</> on
|
||||
parse error.
|
||||
Note that due to the internal representation of the timestamp datatype,
|
||||
Note that due to the internal representation of the <type>timestamp</type> data type,
|
||||
<literal>PGTYPESInvalidTimestamp</literal> is also a valid timestamp at
|
||||
the same time. It is set to <literal>1899-12-31 23:59:59</>. In order
|
||||
to detect errors, make sure that your application does not only test
|
||||
@ -2421,13 +2421,13 @@ EXEC SQL DEALLOCATE DESCRIPTOR <replaceable>identifier</replaceable>;
|
||||
<programlisting>
|
||||
EXEC SQL FETCH NEXT FROM mycursor INTO SQL DESCRIPTOR mydesc;
|
||||
</programlisting>
|
||||
If the resultset is empty, the Descriptor Area will still contain
|
||||
If the result set is empty, the Descriptor Area will still contain
|
||||
the metadata from the query, i.e. the field names.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For not yet executed prepared queries, the <command>DESCRIBE</command>
|
||||
statement can be used to get the metadata of the resultset:
|
||||
statement can be used to get the metadata of the result set:
|
||||
<programlisting>
|
||||
EXEC SQL BEGIN DECLARE SECTION;
|
||||
char *sql_stmt = "SELECT * FROM table1";
|
||||
@ -2449,7 +2449,7 @@ EXEC SQL DESCRIBE stmt1 INTO SQL DESCRIPTOR mydesc;
|
||||
<para>
|
||||
In <command>DESCRIBE</command> and <command>FETCH</command> statements,
|
||||
the <literal>INTO</literal> and <literal>USING</literal> keywords can be
|
||||
used to similarly: they produce the resultset and the metadata in a
|
||||
used to similarly: they produce the result set and the metadata in a
|
||||
Descriptor Area.
|
||||
</para>
|
||||
|
||||
@ -2648,8 +2648,8 @@ EXEC SQL GET DESCRIPTOR mydesc VALUE 1 :id = DATA;
|
||||
|
||||
<para>
|
||||
An SQLDA Descriptor Area is a C language structure which can be also used
|
||||
to get the resultset and the metadata of a query. One structure stores one
|
||||
record from the resultset.
|
||||
to get the result set and the metadata of a query. One structure stores one
|
||||
record from the result set.
|
||||
<programlisting>
|
||||
EXEC SQL include sqlda.h;
|
||||
sqlda_t *mysqlda;
|
||||
@ -2703,7 +2703,7 @@ typedef struct sqlda_struct sqlda_t;
|
||||
|
||||
<para>
|
||||
The allocated data for an SQLDA structure is variable as it depends on the
|
||||
number of fields in a resultset and also depends on the length of the string
|
||||
number of fields in a result set and also depends on the length of the string
|
||||
data values in a record. The individual fields of the <literal>SQLDA</literal>
|
||||
structure are:
|
||||
|
||||
@ -2742,7 +2742,7 @@ typedef struct sqlda_struct sqlda_t;
|
||||
<term><literal>sqld</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
It contains the number of fields in a resultset.
|
||||
It contains the number of fields in a result set.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2759,7 +2759,7 @@ typedef struct sqlda_struct sqlda_t;
|
||||
<term><literal>sqlvar</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is the array of the fields in the resultset. The fields are:
|
||||
This is the array of the fields in the result set. The fields are:
|
||||
|
||||
<variablelist>
|
||||
|
||||
@ -2777,7 +2777,7 @@ typedef struct sqlda_struct sqlda_t;
|
||||
<term><literal>sqllen</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
It contains the binary length of the field. E.g. 4 bytes for ECPGt_int.
|
||||
It contains the binary length of the field. E.g. 4 bytes for <type>ECPGt_int</type>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2851,7 +2851,7 @@ struct sqlname
|
||||
<sect1 id="ecpg-informix-compat">
|
||||
<title><productname>Informix</productname> compatibility mode</title>
|
||||
<para>
|
||||
ecpg can be run in a so-called <firstterm>Informix compatibility mode</>. If
|
||||
<command>ecpg</command> 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 <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
|
||||
@ -2865,20 +2865,20 @@ $COMMIT;
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
There are two compatibility modes: INFORMIX, INFORMIX_SE
|
||||
There are two compatibility modes: <literal>INFORMIX</>, <literal>INFORMIX_SE</>
|
||||
</para>
|
||||
<para>
|
||||
When linking programs that use this compatibility mode, remember to link
|
||||
against <literal>libcompat</> that is shipped with ecpg.
|
||||
against <literal>libcompat</> that is shipped with ECPG.
|
||||
</para>
|
||||
<para>
|
||||
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.
|
||||
well as embedded SQL statements known from E/SQL to ECPG.
|
||||
</para>
|
||||
<para>
|
||||
<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
|
||||
of ECPG. pgtypeslib maps SQL data types to data types within the C host
|
||||
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 <productname>Informix</productname>
|
||||
@ -2888,7 +2888,7 @@ $COMMIT;
|
||||
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
|
||||
find support in ecpg for that either.
|
||||
find support in ECPG for that either.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
@ -2916,7 +2916,7 @@ EXEC SQL FETCH MYCUR INTO :userid;
|
||||
<listitem>
|
||||
<para>
|
||||
This statement closes the current connection. In fact, this is a
|
||||
synonym for ecpg's <literal>DISCONNECT CURRENT</>.:
|
||||
synonym for ECPG's <literal>DISCONNECT CURRENT</>.:
|
||||
<programlisting>
|
||||
$CLOSE DATABASE; /* close the current connection */
|
||||
EXEC SQL CLOSE DATABASE;
|
||||
@ -2929,11 +2929,11 @@ EXEC SQL CLOSE DATABASE;
|
||||
<listitem>
|
||||
<para>
|
||||
Due to the differences how ECPG works compared to Informix's ESQL/C (i.e. which steps
|
||||
are purely grammar transformations and which steps rely on the underlying runtime library)
|
||||
are purely grammar transformations and which steps rely on the underlying run-time library)
|
||||
there is no <literal>FREE cursor_name</> statement in ECPG. This is because in ECPG,
|
||||
<literal>DECLARE CURSOR</literal> doesn't translate to a function call into
|
||||
the runtime library that uses to the cursor name. This means that there's no runtime
|
||||
bookkeeping of SQL cursors in the ECPG runtime library, only in the PostgreSQL server.
|
||||
the run-time library that uses to the cursor name. This means that there's no run-time
|
||||
bookkeeping of SQL cursors in the ECPG run-time library, only in the PostgreSQL server.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3020,7 +3020,7 @@ typedef struct sqlda_compat sqlda_t;
|
||||
<term><literal>desc_name</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Unused, filled with zerobytes.
|
||||
Unused, filled with zero-bytes.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3038,7 +3038,7 @@ typedef struct sqlda_compat sqlda_t;
|
||||
<term><literal>desc_next</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Pointer to the next SQLDA structure if the resultset contains more than one records.
|
||||
Pointer to the next SQLDA structure if the result set contains more than one records.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3126,7 +3126,7 @@ if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
|
||||
<term><literal>sqlformat</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Reserved in Informix, value of PQfformat() for the field.
|
||||
Reserved in Informix, value of <function>PQfformat()</> for the field.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3155,7 +3155,7 @@ if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
|
||||
<term><literal>sqlxid</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Extended type of the field, result of PQftype().
|
||||
Extended type of the field, result of <function>PQftype()</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -3243,9 +3243,9 @@ int decadd(decimal *arg1, decimal *arg2, decimal *sum);
|
||||
(<literal>arg1</>), a pointer to the second operand of type decimal
|
||||
(<literal>arg2</>) and a pointer to a value of type decimal that will
|
||||
contain the sum (<literal>sum</>). On success, the function returns 0.
|
||||
ECPG_INFORMIX_NUM_OVERFLOW is returned in case of overflow and
|
||||
ECPG_INFORMIX_NUM_UNDERFLOW in case of underflow. -1 is returned for
|
||||
other failures and errno is set to the respective errno number of the
|
||||
<symbol>ECPG_INFORMIX_NUM_OVERFLOW</> is returned in case of overflow and
|
||||
<symbol>ECPG_INFORMIX_NUM_UNDERFLOW</> in case of underflow. -1 is returned for
|
||||
other failures and <varname>errno</> is set to the respective <varname>errno</> number of the
|
||||
pgtypeslib.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3530,9 +3530,9 @@ int dectoint(decimal *np, int *ip);
|
||||
is returned.
|
||||
</para>
|
||||
<para>
|
||||
Note that the ecpg implementation differs from the <productname>Informix</productname>
|
||||
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
|
||||
32767, while the limits in the ECPG implementation depend on the
|
||||
architecture (<literal>-INT_MAX .. INT_MAX</>).
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3556,9 +3556,9 @@ int dectolong(decimal *np, long *lngp);
|
||||
is returned.
|
||||
</para>
|
||||
<para>
|
||||
Note that the ecpg implementation differs from the <productname>Informix</productname>
|
||||
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
|
||||
-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</>).
|
||||
</para>
|
||||
@ -3584,9 +3584,9 @@ int rdatestr(date d, char *str);
|
||||
error.
|
||||
</para>
|
||||
<para>
|
||||
Note that ecpg's implementation differs from the <productname>Informix</productname>
|
||||
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
|
||||
environment variables. In ECPG however, you cannot change the output
|
||||
format.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -5129,14 +5129,14 @@ EXEC SQL UNDEF MYNUMBER;
|
||||
Of course you can continue to use the C versions <literal>#define</literal>
|
||||
and <literal>#undef</literal> in your embedded SQL program. The difference
|
||||
is where your defined values get evaluated. If you use <literal>EXEC SQL
|
||||
DEFINE</> then the ecpg preprocessor evaluates the defines and substitutes
|
||||
DEFINE</> then the <command>ecpg</> preprocessor evaluates the defines and substitutes
|
||||
the values. For example if you write:
|
||||
<programlisting>
|
||||
EXEC SQL DEFINE MYNUMBER 12;
|
||||
...
|
||||
EXEC SQL UPDATE Tbl SET col = MYNUMBER;
|
||||
</programlisting>
|
||||
then ecpg will already do the substitution and your C compiler will never
|
||||
then <command>ecpg</> will already do the substitution and your C compiler will never
|
||||
see any name or identifier <literal>MYNUMBER</>. Note that you cannot use
|
||||
<literal>#define</literal> for a constant that you are going to use in an
|
||||
embedded SQL query because in this case the embedded SQL precompiler is not
|
||||
@ -5145,7 +5145,7 @@ EXEC SQL UPDATE Tbl SET col = MYNUMBER;
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>ifdef, ifndef, else, elif and endif directives</title>
|
||||
<title>ifdef, ifndef, else, elif, and endif directives</title>
|
||||
<para>
|
||||
You can use the following directives to compile code sections conditionally:
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.20 2010/06/07 02:01:08 itagaki Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.21 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<appendix id="external-projects">
|
||||
<title>External Projects</title>
|
||||
@ -45,7 +45,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<link linkend="ecpg">ecpg</link> is included because it depends on the
|
||||
<link linkend="ecpg">ECPG</link> is included because it depends on the
|
||||
server-side SQL grammar, and is therefore sensitive to changes in
|
||||
<productname>PostgreSQL</productname> itself.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.528 2010/08/15 21:26:36 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.529 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="functions">
|
||||
<title>Functions and Operators</title>
|
||||
@ -9658,7 +9658,7 @@ SELECT NULLIF(value, '(none)') ...
|
||||
|
||||
<para>
|
||||
Array comparisons compare the array contents element-by-element,
|
||||
using the default B-Tree 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
|
||||
@ -10179,8 +10179,8 @@ SELECT NULLIF(value, '(none)') ...
|
||||
SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;
|
||||
</programlisting>
|
||||
Here <function>ANY</function> can be considered either as introducing
|
||||
a subquery, or as being an aggregate function, if the sub-select
|
||||
returns one row with a boolean value.
|
||||
a subquery, or as being an aggregate function, if the subquery
|
||||
returns one row with a Boolean value.
|
||||
Thus the standard name cannot be given to these aggregates.
|
||||
</para>
|
||||
</note>
|
||||
@ -11415,8 +11415,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 B-Tree operator
|
||||
class, or is the negator of the <literal>=</> member of a B-Tree 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>
|
||||
|
||||
@ -13390,7 +13390,7 @@ postgres=# select pg_start_backup('label_goes_here');
|
||||
0/D4445B8
|
||||
(1 row)
|
||||
</programlisting>
|
||||
There is an optional boolean second parameter. If <literal>true</>,
|
||||
There is an optional second parameter of type <type>boolean</type>. If <literal>true</>,
|
||||
it specifies executing <function>pg_start_backup</> as quickly as
|
||||
possible. This forces an immediate checkpoint which will cause a
|
||||
spike in I/O operations, slowing any concurrently executing queries.
|
||||
@ -13767,7 +13767,7 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup());
|
||||
|
||||
<para>
|
||||
<function>pg_relation_filepath</> is similar to
|
||||
<function>pg_relation_filenode</>, but it returns the entire file pathname
|
||||
<function>pg_relation_filenode</>, but it returns the entire file path name
|
||||
(relative to the database cluster's data directory <varname>PGDATA</>) of
|
||||
the relation.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.7 2010/08/02 23:20:23 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.8 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="fuzzystrmatch">
|
||||
<title>fuzzystrmatch</title>
|
||||
@ -16,7 +16,7 @@
|
||||
<para>
|
||||
At present, the <function>soundex</>, <function>metaphone</>,
|
||||
<function>dmetaphone</>, and <function>dmetaphone_alt</> functions do
|
||||
not work well with multi-byte encodings (such as UTF-8).
|
||||
not work well with multibyte encodings (such as UTF-8).
|
||||
</para>
|
||||
</caution>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.20 2010/04/03 07:22:54 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gin.sgml,v 2.21 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="GIN">
|
||||
<title>GIN Indexes</title>
|
||||
@ -62,11 +62,10 @@
|
||||
<para>
|
||||
The four methods that an operator class for
|
||||
<acronym>GIN</acronym> must provide are:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>int compare(Datum a, Datum b)</term>
|
||||
<term><function>int compare(Datum a, Datum b)</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Compares keys (not indexed values!) and returns an integer less than
|
||||
@ -77,7 +76,7 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Datum *extractValue(Datum inputValue, int32 *nkeys)</term>
|
||||
<term><function>Datum *extractValue(Datum inputValue, int32 *nkeys)</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns an array of keys given a value to be indexed. The
|
||||
@ -87,8 +86,8 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>Datum *extractQuery(Datum query, int32 *nkeys,
|
||||
StrategyNumber n, bool **pmatch, Pointer **extra_data)</term>
|
||||
<term><function>Datum *extractQuery(Datum query, int32 *nkeys,
|
||||
StrategyNumber n, bool **pmatch, Pointer **extra_data)</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns an array of keys given a value to be queried; that is,
|
||||
@ -109,7 +108,7 @@
|
||||
so the index scan can be skipped entirely.
|
||||
<literal>pmatch</> is an output argument for use when partial match
|
||||
is supported. To use it, <function>extractQuery</> must allocate
|
||||
an array of <literal>*nkeys</> booleans and store its address at
|
||||
an array of <literal>*nkeys</> Booleans and store its address at
|
||||
<literal>*pmatch</>. Each element of the array should be set to TRUE
|
||||
if the corresponding key requires partial match, FALSE if not.
|
||||
If <literal>*pmatch</> is set to NULL then GIN assumes partial match
|
||||
@ -133,8 +132,8 @@
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>bool consistent(bool check[], StrategyNumber n, Datum query,
|
||||
int32 nkeys, Pointer extra_data[], bool *recheck)</term>
|
||||
<term><function>bool consistent(bool check[], StrategyNumber n, Datum query,
|
||||
int32 nkeys, Pointer extra_data[], bool *recheck)</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns TRUE if the indexed value satisfies the query operator with
|
||||
@ -156,19 +155,15 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>
|
||||
Optionally, an operator class for
|
||||
<acronym>GIN</acronym> can supply a fifth method:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
|
||||
<varlistentry>
|
||||
<term>int comparePartial(Datum partial_key, Datum key, StrategyNumber n,
|
||||
Pointer extra_data)</term>
|
||||
<term><function>int comparePartial(Datum partial_key, Datum key, StrategyNumber n,
|
||||
Pointer extra_data)</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Compare a partial-match query to an index key. Returns an integer
|
||||
@ -184,8 +179,8 @@
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To support <quote>partial match</> queries, an operator class must
|
||||
@ -408,37 +403,37 @@
|
||||
feature.
|
||||
The following <filename>contrib</> modules also contain
|
||||
<acronym>GIN</acronym> operator classes:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>btree-gin</term>
|
||||
<term><filename>btree_gin</></term>
|
||||
<listitem>
|
||||
<para>B-Tree equivalent functionality for several data types</para>
|
||||
<para>B-tree equivalent functionality for several data types</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>hstore</term>
|
||||
<term><filename>hstore</></term>
|
||||
<listitem>
|
||||
<para>Module for storing (key, value) pairs</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>intarray</term>
|
||||
<term><filename>intarray</></term>
|
||||
<listitem>
|
||||
<para>Enhanced support for int4[]</para>
|
||||
<para>Enhanced support for <type>int[]</type></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>pg_trgm</term>
|
||||
<term><filename>pg_trgm</></term>
|
||||
<listitem>
|
||||
<para>Text similarity using trigram matching</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.31 2009/06/12 19:48:53 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/gist.sgml,v 1.32 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="GiST">
|
||||
<title>GiST Indexes</title>
|
||||
@ -102,7 +102,7 @@
|
||||
<function>decompress</>, which allow an index to have internal tree data of
|
||||
a different type than the data it indexes. The leaves are to be of the
|
||||
indexed data type, while the other tree nodes can be of any C struct (but
|
||||
you still have to follow <productname>PostgreSQL</> datatype rules here,
|
||||
you still have to follow <productname>PostgreSQL</> data type rules here,
|
||||
see about <literal>varlena</> for variable sized data). If the tree's
|
||||
internal data type exists at the SQL level, the <literal>STORAGE</> option
|
||||
of the <command>CREATE OPERATOR CLASS</> command can be used.
|
||||
@ -561,7 +561,7 @@ my_same(PG_FUNCTION_ARGS)
|
||||
</programlisting>
|
||||
|
||||
For historical reasons, the <function>same</> function doesn't
|
||||
just return a boolean result; instead it has to store the flag
|
||||
just return a Boolean result; instead it has to store the flag
|
||||
at the location indicated by the third argument.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -583,58 +583,58 @@ my_same(PG_FUNCTION_ARGS)
|
||||
(see <filename>src/backend/access/gist/gistproc.c</>). The following
|
||||
<filename>contrib</> modules also contain <acronym>GiST</acronym>
|
||||
operator classes:
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>btree_gist</term>
|
||||
<term><filename>btree_gist</></term>
|
||||
<listitem>
|
||||
<para>B-Tree equivalent functionality for several data types</para>
|
||||
<para>B-tree equivalent functionality for several data types</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>cube</term>
|
||||
<term><filename>cube</></term>
|
||||
<listitem>
|
||||
<para>Indexing for multidimensional cubes</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>hstore</term>
|
||||
<term><filename>hstore</></term>
|
||||
<listitem>
|
||||
<para>Module for storing (key, value) pairs</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>intarray</term>
|
||||
<term><filename>intarray</></term>
|
||||
<listitem>
|
||||
<para>RD-Tree for one-dimensional array of int4 values</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>ltree</term>
|
||||
<term><filename>ltree</></term>
|
||||
<listitem>
|
||||
<para>Indexing for tree-like structures</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>pg_trgm</term>
|
||||
<term><filename>pg_trgm</></term>
|
||||
<listitem>
|
||||
<para>Text similarity using trigram matching</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>seg</term>
|
||||
<term><filename>seg</></term>
|
||||
<listitem>
|
||||
<para>Indexing for <quote>float ranges</quote></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.78 2010/07/14 22:04:21 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.79 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="high-availability">
|
||||
<title>High Availability, Load Balancing, and Replication</title>
|
||||
@ -449,7 +449,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
part of the query and return results to a central server where they
|
||||
are combined and returned to the user. <productname>Pgpool-II</>
|
||||
has this capability. Also, this can be implemented using the
|
||||
<productname>PL/Proxy</> toolset.
|
||||
<productname>PL/Proxy</> tool set.
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
@ -602,21 +602,21 @@ protocol to make nodes agree on a serializable transactional order.
|
||||
At startup, the standby begins by restoring all WAL available in the
|
||||
archive location, calling <varname>restore_command</>. Once it
|
||||
reaches the end of WAL available there and <varname>restore_command</>
|
||||
fails, it tries to restore any WAL available in the pg_xlog directory.
|
||||
fails, it tries to restore any WAL available in the <filename>pg_xlog</> directory.
|
||||
If that fails, and streaming replication has been configured, the
|
||||
standby tries to connect to the primary server and start streaming WAL
|
||||
from the last valid record found in archive or pg_xlog. If that fails
|
||||
from the last valid record found in archive or <filename>pg_xlog</>. If that fails
|
||||
or streaming replication is not configured, or if the connection is
|
||||
later disconnected, the standby goes back to step 1 and tries to
|
||||
restore the file from the archive again. This loop of retries from the
|
||||
archive, pg_xlog, and via streaming replication goes on until the server
|
||||
archive, <filename>pg_xlog</>, and via streaming replication goes on until the server
|
||||
is stopped or failover is triggered by a trigger file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Standby mode is exited and the server switches to normal operation,
|
||||
when a trigger file is found (<varname>trigger_file</>). Before failover,
|
||||
any WAL immediately available in the archive or in pg_xlog will be
|
||||
any WAL immediately available in the archive or in <filename>pg_xlog</> will be
|
||||
restored, but no attempt is made to connect to the master.
|
||||
</para>
|
||||
</sect2>
|
||||
@ -753,7 +753,7 @@ trigger_file = '/path/to/trigger_file'
|
||||
too early, while the standby might still need them to catch up. If the
|
||||
standby falls behind too much, it needs to be reinitialized from a new
|
||||
base backup. If you set up a WAL archive that's accessible from the
|
||||
standby, wal_keep_segments is not required as the standby can always
|
||||
standby, <varname>wal_keep_segments</> is not required as the standby can always
|
||||
use the archive to catch up.
|
||||
</para>
|
||||
|
||||
@ -1743,7 +1743,7 @@ LOG: database system is ready to accept read only connections
|
||||
</para>
|
||||
|
||||
<para>
|
||||
New oids cannot be assigned, though some <acronym>UUID</> generators may still
|
||||
New OIDs cannot be assigned, though some <acronym>UUID</> generators may still
|
||||
work as long as they do not rely on writing new status to the database.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.13 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.14 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="hstore">
|
||||
<title>hstore</title>
|
||||
@ -214,7 +214,7 @@ key => NULL
|
||||
and <literal><@</> were called <literal>@</> and <literal>~</>,
|
||||
respectively. These names are still available, but are deprecated and will
|
||||
eventually be removed. Notice that the old names are reversed from the
|
||||
convention formerly followed by the core geometric datatypes!
|
||||
convention formerly followed by the core geometric data types!
|
||||
</para>
|
||||
</note>
|
||||
|
||||
@ -409,7 +409,7 @@ b
|
||||
<para>
|
||||
The function <function>populate_record</function> is actually declared
|
||||
with <type>anyelement</>, not <type>record</>, as its first argument,
|
||||
but it will reject non-record types with a runtime error.
|
||||
but it will reject non-record types with a run-time error.
|
||||
</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.34 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.35 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="indexam">
|
||||
<title>Index Access Method Interface Definition</title>
|
||||
@ -189,7 +189,7 @@ aminsert (Relation indexRelation,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The function's boolean result value is significant only when
|
||||
The function's Boolean result value is significant only when
|
||||
<literal>checkUnique</> is <literal>UNIQUE_CHECK_PARTIAL</>.
|
||||
In this case a TRUE result means the new entry is known unique, whereas
|
||||
FALSE means it might be non-unique (and a deferred uniqueness check must
|
||||
@ -366,7 +366,7 @@ amgetbitmap (IndexScanDesc scan,
|
||||
TIDBitmap *tbm);
|
||||
</programlisting>
|
||||
Fetch all tuples in the given scan and add them to the caller-supplied
|
||||
TIDBitmap (that is, OR the set of tuple IDs into whatever set is already
|
||||
<type>TIDBitmap</type> (that is, OR the set of tuple IDs into whatever set is already
|
||||
in the bitmap). The number of tuples fetched is returned (this might be
|
||||
just an approximate count, for instance some AMs do not detect duplicates).
|
||||
While inserting tuple IDs into the bitmap, <function>amgetbitmap</> can
|
||||
@ -820,19 +820,19 @@ amrestrpos (IndexScanDesc scan);
|
||||
<title>Index Cost Estimation Functions</title>
|
||||
|
||||
<para>
|
||||
The amcostestimate function is given a list of WHERE clauses that have
|
||||
The <function>amcostestimate</> function is given a list of WHERE clauses that have
|
||||
been determined to be usable with the index. It must return estimates
|
||||
of the cost of accessing the index and the selectivity of the WHERE
|
||||
clauses (that is, the fraction of parent-table rows that will be
|
||||
retrieved during the index scan). For simple cases, nearly all the
|
||||
work of the cost estimator can be done by calling standard routines
|
||||
in the optimizer; the point of having an amcostestimate function is
|
||||
in the optimizer; the point of having an <function>amcostestimate</> function is
|
||||
to allow index access methods to provide index-type-specific knowledge,
|
||||
in case it is possible to improve on the standard estimates.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Each amcostestimate function must have the signature:
|
||||
Each <function>amcostestimate</> function must have the signature:
|
||||
|
||||
<programlisting>
|
||||
void
|
||||
@ -850,7 +850,7 @@ amcostestimate (PlannerInfo *root,
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>root</term>
|
||||
<term><parameter>root</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The planner's information about the query being processed.
|
||||
@ -859,7 +859,7 @@ amcostestimate (PlannerInfo *root,
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>index</term>
|
||||
<term><parameter>index</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The index being considered.
|
||||
@ -868,23 +868,23 @@ amcostestimate (PlannerInfo *root,
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>indexQuals</term>
|
||||
<term><parameter>indexQuals</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
List of index qual clauses (implicitly ANDed);
|
||||
a NIL list indicates no qualifiers are available.
|
||||
a <symbol>NIL</> list indicates no qualifiers are available.
|
||||
Note that the list contains expression trees, not ScanKeys.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>outer_rel</term>
|
||||
<term><parameter>outer_rel</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
If the index is being considered for use in a join inner indexscan,
|
||||
the planner's information about the outer side of the join. Otherwise
|
||||
NULL. When non-NULL, some of the qual clauses will be join clauses
|
||||
<symbol>NULL</>. When non-<symbol>NULL</>, some of the qual clauses will be join clauses
|
||||
with this rel rather than being simple restriction clauses. Also,
|
||||
the cost estimator should expect that the index scan will be repeated
|
||||
for each row of the outer rel.
|
||||
@ -899,7 +899,7 @@ amcostestimate (PlannerInfo *root,
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>*indexStartupCost</term>
|
||||
<term><parameter>*indexStartupCost</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set to cost of index start-up processing
|
||||
@ -908,7 +908,7 @@ amcostestimate (PlannerInfo *root,
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>*indexTotalCost</term>
|
||||
<term><parameter>*indexTotalCost</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set to total cost of index processing
|
||||
@ -917,7 +917,7 @@ amcostestimate (PlannerInfo *root,
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>*indexSelectivity</term>
|
||||
<term><parameter>*indexSelectivity</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set to index selectivity
|
||||
@ -926,7 +926,7 @@ amcostestimate (PlannerInfo *root,
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>*indexCorrelation</term>
|
||||
<term><parameter>*indexCorrelation</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set to correlation coefficient between index scan order and
|
||||
@ -951,7 +951,7 @@ amcostestimate (PlannerInfo *root,
|
||||
row should usually be taken as <varname>cpu_index_tuple_cost</>. In
|
||||
addition, an appropriate multiple of <varname>cpu_operator_cost</> should
|
||||
be charged for any comparison operators invoked during index processing
|
||||
(especially evaluation of the indexQuals themselves).
|
||||
(especially evaluation of the <literal>indexQuals</> themselves).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -968,14 +968,14 @@ amcostestimate (PlannerInfo *root,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The indexSelectivity should be set to the estimated fraction of the parent
|
||||
The <parameter>indexSelectivity</> should be set to the estimated fraction of the parent
|
||||
table rows that will be retrieved during the index scan. In the case
|
||||
of a lossy query, this will typically be higher than the fraction of
|
||||
rows that actually pass the given qual conditions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The indexCorrelation should be set to the correlation (ranging between
|
||||
The <parameter>indexCorrelation</> should be set to the correlation (ranging between
|
||||
-1.0 and 1.0) between the index order and the table order. This is used
|
||||
to adjust the estimate for the cost of fetching rows from the parent
|
||||
table.
|
||||
@ -1009,16 +1009,16 @@ amcostestimate (PlannerInfo *root,
|
||||
<step>
|
||||
<para>
|
||||
Estimate the number of index rows that will be visited during the
|
||||
scan. For many index types this is the same as indexSelectivity times
|
||||
scan. For many index types this is the same as <parameter>indexSelectivity</> times
|
||||
the number of rows in the index, but it might be more. (Note that the
|
||||
index's size in pages and rows is available from the IndexOptInfo struct.)
|
||||
index's size in pages and rows is available from the <structname>IndexOptInfo</> struct.)
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<para>
|
||||
Estimate the number of index pages that will be retrieved during the scan.
|
||||
This might be just indexSelectivity times the index's size in pages.
|
||||
This might be just <parameter>indexSelectivity</> times the index's size in pages.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.81 2010/04/03 07:22:54 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.82 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="indexes">
|
||||
<title>Indexes</title>
|
||||
@ -92,9 +92,9 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
|
||||
<para>
|
||||
Creating an index on a large table can take a long time. By default,
|
||||
<productname>PostgreSQL</productname> allows reads (selects) to occur
|
||||
on the table in parallel with index creation, but writes (INSERTs,
|
||||
UPDATEs, DELETEs) are blocked until the index build is finished.
|
||||
<productname>PostgreSQL</productname> allows reads (<command>SELECT</command> statements) to occur
|
||||
on the table in parallel with index creation, but writes (<command>INSERT</command>,
|
||||
<command>UPDATE</command>, <command>DELETE</command>) are blocked until the index build is finished.
|
||||
In production environments this is often unacceptable.
|
||||
It is possible to allow writes to occur in parallel with index
|
||||
creation, but there are several caveats to be aware of —
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.350 2010/07/29 18:29:52 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.351 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
@ -2471,7 +2471,7 @@ createlang: language installation failed: ERROR: could not load library "/opt/d
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The GNU make command is called "make" not "gmake".
|
||||
The GNU make command is called <command>make</command>, not <command>gmake</command>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -2982,7 +2982,7 @@ configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
|
||||
On Solaris 7 and older, the 64-bit version of libc has a buggy
|
||||
<function>vsnprintf</function> routine, which leads to erratic
|
||||
core dumps in PostgreSQL. The simplest known workaround is to
|
||||
force PostgreSQL to use its own version of vsnprintf rather than
|
||||
force PostgreSQL to use its own version of <function>vsnprintf</function> rather than
|
||||
the library copy. To do this, after you
|
||||
run <command>configure</command> edit a file produced by
|
||||
<command>configure</command>:
|
||||
@ -3044,7 +3044,7 @@ LIBOBJS = snprintf.o
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you see the linking of the postgres executable abort with an
|
||||
If you see the linking of the <command>postgres</command> executable abort with an
|
||||
error message like:
|
||||
<screen>
|
||||
Undefined first referenced
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.11 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.12 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="intarray">
|
||||
<title>intarray</title>
|
||||
@ -207,7 +207,7 @@
|
||||
<literal><@</> were respectively called <literal>@</> and <literal>~</>.
|
||||
These names are still available, but are deprecated and will eventually be
|
||||
retired. Notice that the old names are reversed from the convention
|
||||
formerly followed by the core geometric datatypes!)
|
||||
formerly followed by the core geometric data types!)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.7 2010/08/10 20:42:01 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.8 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="isn">
|
||||
<title>isn</title>
|
||||
@ -214,7 +214,7 @@
|
||||
|
||||
<para>
|
||||
The <filename>isn</> module provides the standard comparison operators,
|
||||
plus btree and hash indexing support for all these datatypes. In
|
||||
plus B-tree and hash indexing support for all these data types. In
|
||||
addition there are several specialized functions; shown in <xref linkend="isn-functions">.
|
||||
In this table,
|
||||
<type>isn</> means any one of the module's data types.
|
||||
@ -375,7 +375,7 @@ SELECT isbn13(id) FROM test;
|
||||
|
||||
<para>
|
||||
This module was inspired by Garrett A. Wollman's
|
||||
isbn_issn code.
|
||||
<filename>isbn_issn</> code.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.320 2010/08/10 02:56:46 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.321 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="libpq">
|
||||
<title><application>libpq</application> - C Library</title>
|
||||
@ -79,13 +79,13 @@
|
||||
<para>
|
||||
On Windows, there is a way to improve performance if a single
|
||||
database connection is repeatedly started and shutdown. Internally,
|
||||
libpq calls WSAStartup() and WSACleanup() for connection startup
|
||||
and shutdown, respectively. WSAStartup() increments an internal
|
||||
Windows library reference count which is decremented by WSACleanup().
|
||||
When the reference count is just one, calling WSACleanup() frees
|
||||
libpq calls <function>WSAStartup()</> and <function>WSACleanup()</> for connection startup
|
||||
and shutdown, respectively. <function>WSAStartup()</> increments an internal
|
||||
Windows library reference count which is decremented by <function>WSACleanup()</>.
|
||||
When the reference count is just one, calling <function>WSACleanup()</> frees
|
||||
all resources and all DLLs are unloaded. This is an expensive
|
||||
operation. To avoid this, an application can manually call
|
||||
WSAStartup() so resources will not be freed when the last database
|
||||
<function>WSAStartup()</> so resources will not be freed when the last database
|
||||
connection is closed.
|
||||
</para>
|
||||
</note>
|
||||
@ -405,7 +405,7 @@ PGconn *PQconnectdbParams(const char **keywords, const char **values, int expand
|
||||
<entry><literal>verify-full</></entry>
|
||||
<entry>only try an <acronym>SSL</> connection, verify that
|
||||
the server certificate is issued by a trusted <acronym>CA</> and
|
||||
that the server hostname matches that in the certificate</entry>
|
||||
that the server host name matches that in the certificate</entry>
|
||||
</row>
|
||||
|
||||
</tbody>
|
||||
@ -471,7 +471,7 @@ PGconn *PQconnectdbParams(const char **keywords, const char **values, int expand
|
||||
<listitem>
|
||||
<para>
|
||||
This parameter specifies the location for the secret key used for
|
||||
the client certificate. It can either specify a filename that will
|
||||
the client certificate. It can either specify a file name that will
|
||||
be used instead of the default
|
||||
<filename>~/.postgresql/postgresql.key</>, or it can specify a key
|
||||
obtained from an external <quote>engine</> (engines are
|
||||
@ -953,7 +953,7 @@ PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg);
|
||||
|
||||
<para>
|
||||
Parses a connection string and returns the resulting options as an
|
||||
array; or returns NULL if there is a problem with the connection
|
||||
array; or returns <symbol>NULL</> if there is a problem with the connection
|
||||
string. This can be used to determine
|
||||
the <function>PQconnectdb</function> options in the provided
|
||||
connection string. The return value points to an array of
|
||||
@ -967,10 +967,10 @@ PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If <literal>errmsg</> is not NULL, then <literal>*errmsg</> is set
|
||||
to NULL on success, else to a malloc'd error string explaining
|
||||
If <literal>errmsg</> is not <symbol>NULL</>, then <literal>*errmsg</> is set
|
||||
to <symbol>NULL</> on success, else to a <function>malloc</>'d error string explaining
|
||||
the problem. (It is also possible for <literal>*errmsg</> to be
|
||||
set to NULL even when NULL is returned; this indicates an out-of-memory
|
||||
set to <symbol>NULL</> even when <symbol>NULL</> is returned; this indicates an out-of-memory
|
||||
situation.)
|
||||
</para>
|
||||
|
||||
@ -978,7 +978,7 @@ PQconninfoOption *PQconninfoParse(const char *conninfo, char **errmsg);
|
||||
After processing the options array, free it by passing it to
|
||||
<function>PQconninfoFree</function>. If this is not done, some memory
|
||||
is leaked for each call to <function>PQconninfoParse</function>.
|
||||
Conversely, if an error occurs and <literal>errmsg</> is not NULL,
|
||||
Conversely, if an error occurs and <literal>errmsg</> is not <symbol>NULL</>,
|
||||
be sure to free the error string using <function>PQfreemem</>.
|
||||
</para>
|
||||
|
||||
@ -1974,7 +1974,7 @@ PGresult *PQdescribePrepared(PGconn *conn, const char *stmtName);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<parameter>stmtName</> can be <literal>""</> or NULL to reference
|
||||
<parameter>stmtName</> can be <literal>""</> or <symbol>NULL</> to reference
|
||||
the unnamed statement, otherwise it must be the name of an existing
|
||||
prepared statement. On success, a <structname>PGresult</> with
|
||||
status <literal>PGRES_COMMAND_OK</literal> is returned. The
|
||||
@ -2017,7 +2017,7 @@ PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<parameter>portalName</> can be <literal>""</> or NULL to reference
|
||||
<parameter>portalName</> can be <literal>""</> or <symbol>NULL</> to reference
|
||||
the unnamed portal, otherwise it must be the name of an existing
|
||||
portal. On success, a <structname>PGresult</> with status
|
||||
<literal>PGRES_COMMAND_OK</literal> is returned. The functions
|
||||
@ -3138,7 +3138,7 @@ char *PQescapeLiteral(PGconn *conn, const char *str, size_t length);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On error, <function>PQescapeLiteral</> returns NULL and a suitable
|
||||
On error, <function>PQescapeLiteral</> returns <symbol>NULL</> and a suitable
|
||||
message is stored in the <parameter>conn</> object.
|
||||
</para>
|
||||
|
||||
@ -3201,7 +3201,7 @@ char *PQescapeIdentifier(PGconn *conn, const char *str, size_t length);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On error, <function>PQescapeIdentifier</> returns NULL and a suitable
|
||||
On error, <function>PQescapeIdentifier</> returns <symbol>NULL</> and a suitable
|
||||
message is stored in the <parameter>conn</> object.
|
||||
</para>
|
||||
|
||||
@ -3254,13 +3254,13 @@ size_t PQescapeStringConn(PGconn *conn,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the <parameter>error</> parameter is not NULL, then
|
||||
If the <parameter>error</> parameter is not <symbol>NULL</>, then
|
||||
<literal>*error</> is set to zero on success, nonzero on error.
|
||||
Presently the only possible error conditions involve invalid multibyte
|
||||
encoding in the source string. The output string is still generated
|
||||
on error, but it can be expected that the server will reject it as
|
||||
malformed. On error, a suitable message is stored in the
|
||||
<parameter>conn</> object, whether or not <parameter>error</> is NULL.
|
||||
<parameter>conn</> object, whether or not <parameter>error</> is <symbol>NULL</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -3365,7 +3365,7 @@ unsigned char *PQescapeByteaConn(PGconn *conn,
|
||||
</para>
|
||||
|
||||
<para>
|
||||
On error, a NULL pointer is returned, and a suitable error message
|
||||
On error, a null pointer is returned, and a suitable error message
|
||||
is stored in the <parameter>conn</> object. Currently, the only
|
||||
possible error is insufficient memory for the result string.
|
||||
</para>
|
||||
@ -3438,7 +3438,7 @@ unsigned char *PQunescapeBytea(const unsigned char *from, size_t *to_length);
|
||||
to a <type>bytea</type> column. <function>PQunescapeBytea</function>
|
||||
converts this string representation into its binary representation.
|
||||
It returns a pointer to a buffer allocated with
|
||||
<function>malloc()</function>, or NULL on error, and puts the size of
|
||||
<function>malloc()</function>, or <symbol>NULL</> on error, and puts the size of
|
||||
the buffer in <parameter>to_length</parameter>. The result must be
|
||||
freed using <function>PQfreemem</> when it is no longer needed.
|
||||
</para>
|
||||
@ -3993,7 +3993,7 @@ PGcancel *PQgetCancel(PGconn *conn);
|
||||
<function>PQgetCancel</function> creates a
|
||||
<structname>PGcancel</><indexterm><primary>PGcancel</></> object
|
||||
given a <structname>PGconn</> connection object. It will return
|
||||
NULL if the given <parameter>conn</> is NULL or an invalid
|
||||
<symbol>NULL</> if the given <parameter>conn</> is <symbol>NULL</> or an invalid
|
||||
connection. The <structname>PGcancel</> object is an opaque
|
||||
structure that is not meant to be accessed directly by the
|
||||
application; it can only be passed to <function>PQcancel</function>
|
||||
@ -5078,7 +5078,7 @@ PGresult *PQmakeEmptyPGresult(PGconn *conn, ExecStatusType status);
|
||||
<para>
|
||||
This is <application>libpq</>'s internal function to allocate and
|
||||
initialize an empty <structname>PGresult</structname> object. This
|
||||
function returns NULL if memory could not be allocated. It is
|
||||
function returns <symbol>NULL</> if memory could not be allocated. It is
|
||||
exported because some applications find it useful to generate result
|
||||
objects (particularly objects with error status) themselves. If
|
||||
<parameter>conn</parameter> is not null and <parameter>status</>
|
||||
@ -5117,7 +5117,7 @@ int PQfireResultCreateEvents(PGconn *conn, PGresult *res);
|
||||
|
||||
<para>
|
||||
The <literal>conn</> argument is passed through to event procedures
|
||||
but not used directly. It can be <literal>NULL</> if the event
|
||||
but not used directly. It can be <symbol>NULL</> if the event
|
||||
procedures won't use it.
|
||||
</para>
|
||||
|
||||
@ -5149,7 +5149,7 @@ int PQfireResultCreateEvents(PGconn *conn, PGresult *res);
|
||||
Makes a copy of a <structname>PGresult</structname> object. The copy is
|
||||
not linked to the source result in any way and
|
||||
<function>PQclear</function> must be called when the copy is no longer
|
||||
needed. If the function fails, NULL is returned.
|
||||
needed. If the function fails, <symbol>NULL</> is returned.
|
||||
|
||||
<synopsis>
|
||||
PGresult *PQcopyResult(const PGresult *src, int flags);
|
||||
@ -5193,7 +5193,7 @@ int PQsetResultAttrs(PGresult *res, int numAttributes, PGresAttDesc *attDescs);
|
||||
|
||||
<para>
|
||||
The provided <parameter>attDescs</parameter> are copied into the result.
|
||||
If the <parameter>attDescs</parameter> pointer is NULL or
|
||||
If the <parameter>attDescs</parameter> pointer is <symbol>NULL</> or
|
||||
<parameter>numAttributes</parameter> is less than one, the request is
|
||||
ignored and the function succeeds. If <parameter>res</parameter>
|
||||
already contains attributes, the function will fail. If the function
|
||||
@ -5227,8 +5227,8 @@ int PQsetvalue(PGresult *res, int tup_num, int field_num, char *value, int len);
|
||||
field of any existing tuple can be modified in any order. If a value at
|
||||
<parameter>field_num</parameter> already exists, it will be overwritten.
|
||||
If <parameter>len</parameter> is <literal>-1</literal> or
|
||||
<parameter>value</parameter> is <literal>NULL</literal>, the field value
|
||||
will be set to an SQL <literal>NULL</literal>. The
|
||||
<parameter>value</parameter> is <symbol>NULL</>, the field value
|
||||
will be set to an SQL null value. The
|
||||
<parameter>value</parameter> is copied into the result's private storage,
|
||||
thus is no longer needed after the function
|
||||
returns. If the function fails, the return value is zero. If the
|
||||
@ -5256,7 +5256,7 @@ void *PQresultAlloc(PGresult *res, size_t nBytes);
|
||||
<para>
|
||||
Any memory allocated with this function will be freed when
|
||||
<parameter>res</parameter> is cleared. If the function fails,
|
||||
the return value is <literal>NULL</literal>. The result is
|
||||
the return value is <symbol>NULL</>. The result is
|
||||
guaranteed to be adequately aligned for any type of data,
|
||||
just as for <function>malloc</>.
|
||||
</para>
|
||||
@ -5399,7 +5399,7 @@ defaultNoticeProcessor(void *arg, const char *message)
|
||||
life of the <structname>PGconn</> and all <structname>PGresult</>s
|
||||
generated from it; so if used, it must point to long-lived data.
|
||||
In addition there is an <firstterm>instance data</> pointer, which starts
|
||||
out NULL in every <structname>PGconn</> and <structname>PGresult</>.
|
||||
out <symbol>NULL</> in every <structname>PGconn</> and <structname>PGresult</>.
|
||||
This pointer can be manipulated using the
|
||||
<function>PQinstanceData</function>,
|
||||
<function>PQsetInstanceData</function>,
|
||||
@ -5704,11 +5704,11 @@ int PQregisterEventProc(PGconn *conn, PGEventProc proc,
|
||||
event is fired. Its memory address is also used to lookup
|
||||
<literal>instanceData</literal>. The <parameter>name</parameter>
|
||||
argument is used to refer to the event procedure in error messages.
|
||||
This value cannot be NULL or a zero-length string. The name string is
|
||||
This value cannot be <symbol>NULL</> or a zero-length string. The name string is
|
||||
copied into the <structname>PGconn</>, so what is passed need not be
|
||||
long-lived. The <parameter>passThrough</parameter> pointer is passed
|
||||
to the <parameter>proc</parameter> whenever an event occurs. This
|
||||
argument can be NULL.
|
||||
argument can be <symbol>NULL</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -5722,9 +5722,11 @@ int PQregisterEventProc(PGconn *conn, PGEventProc proc,
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the conn's instanceData for proc to data. This returns non-zero
|
||||
for success and zero for failure. (Failure is only possible if
|
||||
the proc has not been properly registered in the conn.)
|
||||
Sets the connection <parameter>conn</>'s <literal>instanceData</>
|
||||
for procedure <parameter>proc</> to <parameter>data</>. This
|
||||
returns non-zero for success and zero for failure. (Failure is
|
||||
only possible if <parameter>proc</> has not been properly
|
||||
registered in <parameter>conn</>.)
|
||||
|
||||
<synopsis>
|
||||
int PQsetInstanceData(PGconn *conn, PGEventProc proc, void *data);
|
||||
@ -5742,8 +5744,10 @@ int PQsetInstanceData(PGconn *conn, PGEventProc proc, void *data);
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the conn's instanceData associated with proc, or NULL
|
||||
if there is none.
|
||||
Returns the
|
||||
connection <parameter>conn</>'s <literal>instanceData</literal>
|
||||
associated with procedure <parameter>proc</>,
|
||||
or <symbol>NULL</symbol> if there is none.
|
||||
|
||||
<synopsis>
|
||||
void *PQinstanceData(const PGconn *conn, PGEventProc proc);
|
||||
@ -5761,9 +5765,11 @@ void *PQinstanceData(const PGconn *conn, PGEventProc proc);
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Sets the result's instanceData for proc to data. This returns non-zero
|
||||
for success and zero for failure. (Failure is only possible if the
|
||||
proc has not been properly registered in the result.)
|
||||
Sets the result's <literal>instanceData</>
|
||||
for <parameter>proc</> to <parameter>data</>. This returns
|
||||
non-zero for success and zero for failure. (Failure is only
|
||||
possible if <parameter>proc</> has not been properly registered
|
||||
in the result.)
|
||||
|
||||
<synopsis>
|
||||
int PQresultSetInstanceData(PGresult *res, PGEventProc proc, void *data);
|
||||
@ -5781,7 +5787,7 @@ int PQresultSetInstanceData(PGresult *res, PGEventProc proc, void *data);
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Returns the result's instanceData associated with proc, or NULL
|
||||
Returns the result's <literal>instanceData</> associated with <parameter>proc</>, or <symbol>NULL</>
|
||||
if there is none.
|
||||
|
||||
<synopsis>
|
||||
@ -6513,7 +6519,7 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
|
||||
libpq will verify that the server is trustworthy by checking the
|
||||
certificate chain up to a trusted certificate authority
|
||||
(<acronym>CA</>). If <literal>sslmode</> is set to <literal>verify-full</>,
|
||||
libpq will <emphasis>also</> verify that the server hostname matches its
|
||||
libpq will <emphasis>also</> verify that the server host name matches its
|
||||
certificate. The SSL connection will fail if the server certificate cannot
|
||||
be verified. <literal>verify-full</> is recommended in most
|
||||
security-sensitive environments.
|
||||
@ -6521,11 +6527,11 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
|
||||
|
||||
<para>
|
||||
In <literal>verify-full</> mode, the <literal>cn</> (Common Name) attribute
|
||||
of the certificate is matched against the hostname. If the <literal>cn</>
|
||||
of the certificate is matched against the host name. If the <literal>cn</>
|
||||
attribute starts with an asterisk (<literal>*</>), it will be treated as
|
||||
a wildcard, and will match all characters <emphasis>except</> a dot
|
||||
(<literal>.</>). This means the certificate will not match subdomains.
|
||||
If the connection is made using an IP address instead of a hostname, the
|
||||
If the connection is made using an IP address instead of a host name, the
|
||||
IP address will be matched (without doing any DNS lookups).
|
||||
</para>
|
||||
|
||||
@ -6617,7 +6623,7 @@ ldap://ldap.acme.com/cn=dbserver,cn=hosts?pgconnectinfo?base?(objectclass=*)
|
||||
<entry>Eavesdropping</entry>
|
||||
<entry>If a third party can examine the network traffic between the
|
||||
client and the server, it can read both connection information (including
|
||||
the username and password) and the data that is passed. <acronym>SSL</>
|
||||
the user name and password) and the data that is passed. <acronym>SSL</>
|
||||
uses encryption to prevent this.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.4 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.5 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="lo">
|
||||
<title>lo</title>
|
||||
@ -19,7 +19,7 @@
|
||||
<para>
|
||||
One of the problems with the JDBC driver (and this affects the ODBC driver
|
||||
also), is that the specification assumes that references to BLOBs (Binary
|
||||
Large OBjects) are stored within a table, and if that entry is changed, the
|
||||
Large Objects) are stored within a table, and if that entry is changed, the
|
||||
associated BLOB is deleted from the database.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.6 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="ltree">
|
||||
<title>ltree</title>
|
||||
@ -42,7 +42,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <filename>ltree</> module provides several datatypes:
|
||||
The <filename>ltree</> module provides several data types:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.83 2010/08/14 02:22:10 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.84 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="monitoring">
|
||||
<title>Monitoring Database Activity</title>
|
||||
@ -807,7 +807,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
|
||||
<entry><literal><function>pg_stat_get_activity</function>(<type>integer</type>)</literal></entry>
|
||||
<entry><type>setof record</type></entry>
|
||||
<entry>
|
||||
Returns a record of information about the backend with the specified pid, or
|
||||
Returns a record of information about the backend with the specified PID, or
|
||||
one record for each active backend in the system if <symbol>NULL</symbol> is
|
||||
specified. The fields returned are a subset of those in the
|
||||
<structname>pg_stat_activity</structname> view.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.9 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.10 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="oid2name">
|
||||
<title>oid2name</title>
|
||||
@ -105,7 +105,7 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-U</option> <replaceable>username</></term>
|
||||
<listitem><para>username to connect as</para></listitem>
|
||||
<listitem><para>user name to connect as</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -122,8 +122,8 @@
|
||||
using <option>-o</>, <option>-f</> and/or <option>-t</>.
|
||||
<option>-o</> takes an OID,
|
||||
<option>-f</> takes a filenode,
|
||||
and <option>-t</> takes a tablename (actually, it's a LIKE
|
||||
pattern, so you can use things like <option>foo%</>).
|
||||
and <option>-t</> takes a table name (actually, it's a <literal>LIKE</>
|
||||
pattern, so you can use things like <literal>foo%</>).
|
||||
You can use as many
|
||||
of these options as you like, and the listing will include all objects
|
||||
matched by any of the options. But note that these options can only
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.7 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.8 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="pageinspect">
|
||||
<title>pageinspect</title>
|
||||
@ -107,7 +107,7 @@ test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
<function>bt_metap</function> returns information about a btree
|
||||
<function>bt_metap</function> returns information about a B-tree
|
||||
index's metapage. For example:
|
||||
<screen>
|
||||
test=# SELECT * FROM bt_metap('pg_cast_oid_index');
|
||||
@ -131,7 +131,7 @@ fastlevel | 0
|
||||
<listitem>
|
||||
<para>
|
||||
<function>bt_page_stats</function> returns summary information about
|
||||
single pages of btree indexes. For example:
|
||||
single pages of B-tree indexes. For example:
|
||||
<screen>
|
||||
test=# SELECT * FROM bt_page_stats('pg_cast_oid_index', 1);
|
||||
-[ RECORD 1 ]-+-----
|
||||
@ -159,7 +159,7 @@ btpo_flags | 3
|
||||
<listitem>
|
||||
<para>
|
||||
<function>bt_page_items</function> returns detailed information about
|
||||
all of the items on a btree index page. For example:
|
||||
all of the items on a B-tree index page. For example:
|
||||
<screen>
|
||||
test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
|
||||
itemoffset | ctid | itemlen | nulls | vars | data
|
||||
@ -185,7 +185,7 @@ test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
|
||||
<listitem>
|
||||
<para>
|
||||
<function>fsm_page_contents</function> shows the internal node structure
|
||||
of a FSM page. The output is a multi-line string, with one line per
|
||||
of a FSM page. The output is a multiline string, with one line per
|
||||
node in the binary tree within the page. Only those nodes that are not
|
||||
zero are printed. The so-called "next" pointer, which points to the
|
||||
next slot to be returned from the page, is also printed.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.3 2010/08/15 20:20:30 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.4 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgarchivecleanup">
|
||||
<title>pg_archivecleanup</title>
|
||||
@ -61,11 +61,11 @@ pg_archivecleanup <optional> <replaceable>option</> ... </optional> <replaceable
|
||||
</synopsis>
|
||||
When used as a standalone program all WAL files logically preceding the
|
||||
<literal>restartwalfile</> will be removed <replaceable>archivelocation</>.
|
||||
In this mode, if you specify a .backup filename, then only the file prefix
|
||||
In this mode, if you specify a <filename>.backup</> file name, then only the file prefix
|
||||
will be used as the <literal>restartwalfile</>. This allows you to remove
|
||||
all WAL files archived prior to a specific base backup without error.
|
||||
For example, the following example will remove all files older than
|
||||
WAL filename 000000010000003700000010:
|
||||
WAL file name <filename>000000010000003700000010</>:
|
||||
<programlisting>
|
||||
pg_archivecleanup -d archive 000000010000003700000010.00000020.backup
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.19 2010/08/15 19:46:24 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.20 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgbench">
|
||||
<title>pgbench</title>
|
||||
@ -242,7 +242,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<term><option>-l</option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Write the time taken by each transaction to a logfile.
|
||||
Write the time taken by each transaction to a log file.
|
||||
See below for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -380,7 +380,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<term><option>-h</option> <replaceable>hostname</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The database server's hostname
|
||||
The database server's host name
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -398,7 +398,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
<term><option>-U</option> <replaceable>login</></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The username to connect as
|
||||
The user name to connect as
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -447,7 +447,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The format of a script file is one SQL command per line; multi-line
|
||||
The format of a script file is one SQL command per line; multiline
|
||||
SQL commands are not supported. Empty lines and lines beginning with
|
||||
<literal>--</> are ignored. Script file lines can also be
|
||||
<quote>meta commands</>, which are interpreted by <application>pgbench</>
|
||||
@ -626,7 +626,7 @@ END;
|
||||
|
||||
<para>
|
||||
With the <literal>-l</> option, <application>pgbench</> writes the time
|
||||
taken by each transaction to a logfile. The logfile will be named
|
||||
taken by each transaction to a log file. The log file will be named
|
||||
<filename>pgbench_log.<replaceable>nnn</></filename>, where
|
||||
<replaceable>nnn</> is the PID of the pgbench process.
|
||||
If the <literal>-j</> option is 2 or higher, creating multiple worker
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgcrypto.sgml,v 1.12 2010/08/15 01:57:03 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgcrypto.sgml,v 1.13 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgcrypto">
|
||||
<title>pgcrypto</title>
|
||||
@ -519,7 +519,7 @@ pgp_sym_decrypt_bytea(msg bytea, psw text [, options text ]) returns bytea
|
||||
Decrypt a symmetric-key-encrypted PGP message.
|
||||
</para>
|
||||
<para>
|
||||
Decrypting bytea data with <function>pgp_sym_decrypt</> is disallowed.
|
||||
Decrypting <type>bytea</> data with <function>pgp_sym_decrypt</> is disallowed.
|
||||
This is to avoid outputting invalid character data. Decrypting
|
||||
originally textual data with <function>pgp_sym_decrypt_bytea</> is fine.
|
||||
</para>
|
||||
@ -561,7 +561,7 @@ pgp_pub_decrypt_bytea(msg bytea, key bytea [, psw text [, options text ]]) retur
|
||||
options, you need to give an empty password.
|
||||
</para>
|
||||
<para>
|
||||
Decrypting bytea data with <function>pgp_pub_decrypt</> is disallowed.
|
||||
Decrypting <type>bytea</> data with <function>pgp_pub_decrypt</> is disallowed.
|
||||
This is to avoid outputting invalid character data. Decrypting
|
||||
originally textual data with <function>pgp_pub_decrypt_bytea</> is fine.
|
||||
</para>
|
||||
@ -621,7 +621,7 @@ armor(data bytea) returns text
|
||||
dearmor(data text) returns bytea
|
||||
</synopsis>
|
||||
<para>
|
||||
These functions wrap/unwrap binary data into PGP Ascii Armor format,
|
||||
These functions wrap/unwrap binary data into PGP ASCII-armor format,
|
||||
which is basically Base64 with CRC and additional formatting.
|
||||
</para>
|
||||
</sect3>
|
||||
@ -825,13 +825,13 @@ gpg --list-secret-keys
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
To export a public key in ascii-armor format:
|
||||
To export a public key in ASCII-armor format:
|
||||
<programlisting>
|
||||
gpg -a --export KEYID > public.key
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
To export a secret key in ascii-armor format:
|
||||
To export a secret key in ASCII-armor format:
|
||||
<programlisting>
|
||||
gpg -a --export-secret-keys KEYID > secret.key
|
||||
</programlisting>
|
||||
@ -1206,7 +1206,7 @@ gen_random_bytes(count integer) returns bytea
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><ulink url="http://jlcooke.ca/random/"></ulink></para>
|
||||
<para>Jean-Luc Cooke Fortuna-based /dev/random driver for Linux.</para>
|
||||
<para>Jean-Luc Cooke Fortuna-based <filename>/dev/random</> driver for Linux.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><ulink url="http://research.cyber.ee/~lipmaa/crypto/"></ulink></para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.7 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.8 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgfreespacemap">
|
||||
<title>pg_freespacemap</title>
|
||||
@ -33,7 +33,6 @@
|
||||
<para>
|
||||
Returns the amount of free space on the page of the relation, specified
|
||||
by <literal>blkno</>, according to the FSM.
|
||||
(blkno).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -56,7 +55,7 @@
|
||||
|
||||
<para>
|
||||
The values stored in the free space map are not exact. They're rounded
|
||||
to precision of 1/256th of BLCKSZ (32 bytes with default BLCKSZ), and
|
||||
to precision of 1/256th of <symbol>BLCKSZ</> (32 bytes with default <symbol>BLCKSZ</>), and
|
||||
they're not kept fully up-to-date as tuples are inserted and updated.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.12 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.13 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgstandby">
|
||||
<title>pg_standby</title>
|
||||
@ -202,7 +202,7 @@ pg_standby <optional> <replaceable>option</> ... </optional> <replaceable>archiv
|
||||
<listitem>
|
||||
<para>
|
||||
Specify a trigger file whose presence should cause failover.
|
||||
It is recommended that you use a structured filename to
|
||||
It is recommended that you use a structured file name to
|
||||
avoid confusion as to which server is being triggered
|
||||
when multiple servers exist on the same system; for example
|
||||
<filename>/tmp/pgsql.trigger.5432</>.
|
||||
@ -326,7 +326,7 @@ recovery_end_command = 'del C:\pgsql.trigger.5442'
|
||||
|
||||
<para>
|
||||
The <literal>copy</> command on Windows sets the final file size
|
||||
before the file is completely copied, which would ordinarly confuse
|
||||
before the file is completely copied, which would ordinarily confuse
|
||||
<application>pg_standby</application>. Therefore
|
||||
<application>pg_standby</application> waits <literal>sleeptime</>
|
||||
seconds once it sees the proper file size. GNUWin32's <literal>cp</>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstattuple.sgml,v 1.7 2010/08/10 20:42:01 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstattuple.sgml,v 1.8 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgstattuple">
|
||||
<title>pgstattuple</title>
|
||||
@ -140,7 +140,7 @@ free_percent | 1.95
|
||||
<listitem>
|
||||
<para>
|
||||
<function>pgstatindex</function> returns a record showing information
|
||||
about a btree index. For example:
|
||||
about a B-tree index. For example:
|
||||
<programlisting>
|
||||
test=> SELECT * FROM pgstatindex('pg_cast_oid_index');
|
||||
-[ RECORD 1 ]------+------
|
||||
@ -174,7 +174,7 @@ leaf_fragmentation | 0
|
||||
<row>
|
||||
<entry><structfield>version</structfield></entry>
|
||||
<entry><type>integer</type></entry>
|
||||
<entry>Btree version number</entry>
|
||||
<entry>B-tree version number</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgtrgm.sgml,v 2.3 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgtrgm.sgml,v 2.4 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgtrgm">
|
||||
<title>pg_trgm</title>
|
||||
@ -130,7 +130,7 @@
|
||||
operator classes that allow you to create an index over a text column for
|
||||
the purpose of very fast similarity searches. These index types support
|
||||
the <literal>%</> similarity operator (and no other operators, so you may
|
||||
want a regular btree index too).
|
||||
want a regular B-tree index too).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgupgrade.sgml,v 1.13 2010/07/25 03:28:32 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgupgrade.sgml,v 1.14 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="pgupgrade">
|
||||
<title>pg_upgrade</title>
|
||||
@ -8,21 +8,21 @@
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<application>pg_upgrade</> (formerly called pg_migrator) allows data
|
||||
<application>pg_upgrade</> (formerly called <application>pg_migrator</>) allows data
|
||||
stored in <productname>PostgreSQL</> data files to be migrated to a later <productname>PostgreSQL</>
|
||||
major version without the data dump/reload typically required for
|
||||
major version upgrades, e.g. from 8.4.7 to the current major release
|
||||
of <productname>PostgreSQL</>. It is not required for minor version upgrades, e.g
|
||||
9.0.1 -> 9.0.4.
|
||||
of <productname>PostgreSQL</>. It is not required for minor version upgrades, e.g. from
|
||||
9.0.1 to 9.0.4.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>pg_upgrade</> works because, though new features are
|
||||
regularly added to Postgres major releases, the internal data storage
|
||||
regularly added to PostgreSQL major releases, the internal data storage
|
||||
format rarely changes. <application>pg_upgrade</> does its best to
|
||||
make sure the old and new clusters are binary-compatible, e.g. by
|
||||
checking for compatible compile-time settings. It is important that
|
||||
any external modules are also binary compatibile, though this cannot
|
||||
any external modules are also binary compatible, though this cannot
|
||||
be checked by <application>pg_upgrade</>.
|
||||
</para>
|
||||
|
||||
@ -144,50 +144,43 @@
|
||||
<sect2>
|
||||
<title>Upgrade Steps</title>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Optionally move the old cluster
|
||||
</para>
|
||||
<procedure>
|
||||
<step performance="optional">
|
||||
<title>Optionally move the old cluster</title>
|
||||
|
||||
<para>
|
||||
If you are using a version-specific installation directory, e.g.
|
||||
/opt/PostgreSQL/8.4, you do not need to move the old cluster. The
|
||||
one-click installers all use version-specific install directories.
|
||||
<filename>/opt/PostgreSQL/8.4</>, you do not need to move the old cluster. The
|
||||
one-click installers all use version-specific installation directories.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If your installation directory is not version-specific, e.g.
|
||||
/usr/local/pgsql, it is necessary to move the current PostgreSQL install
|
||||
<filename>/usr/local/pgsql</>, it is necessary to move the current PostgreSQL install
|
||||
directory so it does not interfere with the new <productname>PostgreSQL</> installation.
|
||||
Once the current <productname>PostgreSQL</> server is shut down, it is safe to rename the
|
||||
PostgreSQL install directory; assuming the old directory is
|
||||
/usr/local/pgsql, you can do:
|
||||
PostgreSQL installation directory; assuming the old directory is
|
||||
<filename>/usr/local/pgsql</>, you can do:
|
||||
|
||||
<programlisting>
|
||||
mv /usr/local/pgsql /usr/local/pgsql.old
|
||||
</programlisting>
|
||||
to rename the directory.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
For source installs, build the new version
|
||||
</para>
|
||||
<step>
|
||||
<title>For source installs, build the new version</title>
|
||||
|
||||
<para>
|
||||
Build the new PostgreSQL source with configure flags that are compatible
|
||||
Build the new PostgreSQL source with <command>configure</> flags that are compatible
|
||||
with the old cluster. <application>pg_upgrade</> will check <command>pg_controldata</> to make
|
||||
sure all settings are compatible before starting the upgrade.
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Install the new PostgreSQL binaries
|
||||
</para>
|
||||
<step>
|
||||
<title>Install the new PostgreSQL binaries</title>
|
||||
|
||||
<para>
|
||||
Install the new server's binaries and support files. You can use the
|
||||
@ -197,75 +190,67 @@ mv /usr/local/pgsql /usr/local/pgsql.old
|
||||
|
||||
<para>
|
||||
For source installs, if you wish to install the new server in a custom
|
||||
location, use 'prefix':
|
||||
location, use the <literal>prefix</literal> variable:
|
||||
|
||||
<programlisting>
|
||||
gmake prefix=/usr/local/pgsql.new install
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>Install pg_upgrade</title>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Install <application>pg_upgrade</> and
|
||||
<application>pg_upgrade_support</> in the new PostgreSQL cluster
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Initialize the new PostgreSQL cluster
|
||||
</para>
|
||||
<step>
|
||||
<title>Initialize the new PostgreSQL cluster</title>
|
||||
|
||||
<para>
|
||||
Initialize the new cluster <xref
|
||||
linkend="app-initdb">,<indexterm><primary>initdb</></>.
|
||||
Again, use compatible initdb
|
||||
Initialize the new cluster using <command>initdb</command>.
|
||||
Again, use compatible <command>initdb</command>
|
||||
flags that match the old cluster. Many
|
||||
prebuilt installers do this step automatically. There is no need to
|
||||
start the new cluster.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Install custom shared object files (or DLLs)
|
||||
</para>
|
||||
<step>
|
||||
<title>Install custom shared object files</title>
|
||||
|
||||
<para>
|
||||
Install any custom shared object files (or DLLs) used by the old cluster
|
||||
into the new cluster, e.g. pgcrypto.so, whether they are from /contrib
|
||||
into the new cluster, e.g. <filename>pgcrypto.so</filename>, whether they are from <filename>contrib</filename>
|
||||
or some other source. Do not install the schema definitions, e.g.
|
||||
pgcrypto.sql --- these will be migrated from the old cluster.
|
||||
<filename>pgcrypto.sql</>, because these will be migrated from the old cluster.
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Adjust authentication
|
||||
</para>
|
||||
<step>
|
||||
<title>Adjust authentication</title>
|
||||
|
||||
<para>
|
||||
pg_upgrade will connect to the old and new servers several times,
|
||||
<command>pg_upgrade</> will connect to the old and new servers several times,
|
||||
so you might want to set authentication to <literal>trust</> in
|
||||
<filename>pg_hba.conf</>, or if using <literal>md5</> authentication,
|
||||
use a <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">)
|
||||
to avoid being prompted repeatedly for a password.
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Stop both servers
|
||||
</para>
|
||||
<step>
|
||||
<title>Stop both servers</title>
|
||||
|
||||
<para>
|
||||
Make sure both database servers are stopped using on Unix, e.g.:
|
||||
|
||||
<programlisting>
|
||||
pg_ctl --pgdata /opt/PostgreSQL/8.4 stop
|
||||
pg_ctl --pgdata /opt/PostgreSQL/9.0 stop
|
||||
pg_ctl -D /opt/PostgreSQL/8.4 stop
|
||||
pg_ctl -D /opt/PostgreSQL/9.0 stop
|
||||
</programlisting>
|
||||
|
||||
or on Windows
|
||||
@ -281,27 +266,25 @@ NET STOP postgresql-9.0
|
||||
NET STOP pgsql-8.3 (<productname>PostgreSQL</> 8.3 and older used a different service name)
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Run <application>pg_upgrade</>
|
||||
</para>
|
||||
<step>
|
||||
<title>Run <application>pg_upgrade</></title>
|
||||
|
||||
<para>
|
||||
Always run the <application>pg_upgrade</> binary in the new server, not the old one.
|
||||
<application>pg_upgrade</> requires the specification of the old and new cluster's
|
||||
<varname>PGDATA</> and executable (/bin) directories. You can also specify separate
|
||||
data and executable (<filename>bin</>) directories. You can also specify separate
|
||||
user and port values, and whether you want the data linked instead of
|
||||
copied (the default). If you use linking, the migration will be much
|
||||
faster (no data copying), but you will no longer be able to access your
|
||||
old cluster once you start the new cluster after the upgrade. See
|
||||
pg_upgrade --help for a full list of options.
|
||||
<literal>pg_upgrade --help</> for a full list of options.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For Windows users, you must be logged into an administrative account, and
|
||||
then start a shell as the 'postgres' user and set the proper path:
|
||||
then start a shell as the <literal>postgres</> user and set the proper path:
|
||||
|
||||
<programlisting>
|
||||
RUNAS /USER:postgres "CMD.EXE"
|
||||
@ -318,10 +301,10 @@ pg_upgrade.exe
|
||||
--new-bindir "C:/Program Files/PostgreSQL/9.0/bin"
|
||||
</programlisting>
|
||||
|
||||
Once started, pg_upgrade will verify the two clusters are compatible
|
||||
and then do the migration. You can use pg_upgrade <option>--check</>
|
||||
Once started, <command>pg_upgrade</> will verify the two clusters are compatible
|
||||
and then do the migration. You can use <command>pg_upgrade --check</>
|
||||
to perform only the checks, even if the old server is still
|
||||
running. pg_upgrade <option>--check</> will also outline any
|
||||
running. <command>pg_upgrade --check</> will also outline any
|
||||
manual adjustments you will need to make after the migration.
|
||||
</para>
|
||||
|
||||
@ -330,31 +313,27 @@ pg_upgrade.exe
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If an error occurs while restoring the database schema, pg_upgrade will
|
||||
exit and you will have to revert to the old cluster as outlined in step
|
||||
#15 below. To try pg_upgrade again, you will need to modify the old
|
||||
If an error occurs while restoring the database schema, <command>pg_upgrade</> will
|
||||
exit and you will have to revert to the old cluster as outlined in <xref linkend="pgupgrade-step-revert">
|
||||
below. To try <command>pg_upgrade</command> again, you will need to modify the old
|
||||
cluster so the pg_upgrade schema restore succeeds. If the problem is a
|
||||
/contrib module, you might need to uninstall the /contrib module from
|
||||
contrib module, you might need to uninstall the contrib module from
|
||||
the old cluster and install it in the new cluster after the migration,
|
||||
assuming the module is not being used to store user data.
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Restore <filename>pg_hba.conf</>
|
||||
</para>
|
||||
<step>
|
||||
<title>Restore <filename>pg_hba.conf</></title>
|
||||
|
||||
<para>
|
||||
If you modified <filename>pg_hba.conf</> to use <literal>trust</>,
|
||||
restore its original authentication settings.
|
||||
</para>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Post-Migration processing
|
||||
</para>
|
||||
<step>
|
||||
<title>Post-migration processing</title>
|
||||
|
||||
<para>
|
||||
If any post-migration processing is required, pg_upgrade will issue
|
||||
@ -379,76 +358,81 @@ psql --username postgres --file script.sql postgres
|
||||
scripts can be accessed immediately.
|
||||
</para>
|
||||
</caution>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>Statistics</title>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Statistics
|
||||
</para>
|
||||
<caution>
|
||||
<para>
|
||||
Because optimizer statistics are not transferred by pg_upgrade, you will
|
||||
Because optimizer statistics are not transferred by <command>pg_upgrade</>, you will
|
||||
be instructed to run a command to regenerate that information at the end
|
||||
of the migration.
|
||||
</para>
|
||||
</caution>
|
||||
</listitem>
|
||||
</step>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Delete old cluster
|
||||
</para>
|
||||
<step>
|
||||
<title>Delete old cluster</title>
|
||||
|
||||
<para>
|
||||
Once you are satisfied with the upgrade, you can delete the old
|
||||
cluster's data directories by running the script mentioned when
|
||||
pg_upgrade completes. You will need to manually delete the old install
|
||||
directories, e.g. /bin, /share.
|
||||
<command>pg_upgrade</command> completes. You can also delete the
|
||||
old installation directories
|
||||
(e.g. <filename>bin</>, <filename>share</>).
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step id="pgupgrade-step-revert" performance="optional">
|
||||
<title>Reverting to old cluster</title>
|
||||
|
||||
<para>
|
||||
If, after running <command>pg_upgrade</command>, you wish to revert to the old cluster,
|
||||
there are several options:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
If you ran <command>pg_upgrade</command>
|
||||
with <option>--check</>, no modifications were made to the old
|
||||
cluster and you can re-use it anytime.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Reverting to old cluster
|
||||
If you ran <command>pg_upgrade</command>
|
||||
with <option>--link</>, the data files are shared between the
|
||||
old and new cluster. If you started the new cluster, the new
|
||||
server has written to those shared files and it is unsafe to
|
||||
use the old cluster.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
If, after running pg_upgrade, you wish to revert to the old cluster,
|
||||
there are several options.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you ran pg_upgrade with <option>--check</>, no modifications
|
||||
were made to the old cluster and you can re-use it anytime.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you ran pg_upgrade with <option>--link</>, the data files
|
||||
are shared between the old and new cluster. If you started
|
||||
the new cluster, the new server has written to those shared
|
||||
files and it is unsafe to use the old cluster.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you ran pg_upgrade <emphasis>without</>_ <option>--link</>
|
||||
If you
|
||||
ran <command>pg_upgrade</command> <emphasis>without</> <option>--link</>
|
||||
or did not start the new server, the old cluster was not
|
||||
modified except that an <literal>.old</> suffix was appended
|
||||
to <filename>$PGDATA/global/pg_control</> and perhaps tablespace
|
||||
directories. To reuse the old cluster, remove the ".old"
|
||||
suffix from <filename>$PGDATA/global/pg_control</>. and, if
|
||||
migrating to 8.4 or earlier, remove the tablespace directories
|
||||
created by the migration and remove the ".old" suffix from
|
||||
to <filename>$PGDATA/global/pg_control</> and perhaps
|
||||
tablespace directories. To reuse the old cluster, remove
|
||||
the <filename>.old</> suffix
|
||||
from <filename>$PGDATA/global/pg_control</>. and, if migrating
|
||||
to 8.4 or earlier, remove the tablespace directories created
|
||||
by the migration and remove the <filename>.old</> suffix from
|
||||
the tablespace directory names; then you can restart the old
|
||||
cluster.
|
||||
</para>
|
||||
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</step>
|
||||
</procedure>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Limitations in migrating <emphasis>from</> PostgreSQL 8.3</title>
|
||||
<title>Limitations in Migrating <emphasis>from</> PostgreSQL 8.3</title>
|
||||
|
||||
<para>
|
||||
Upgrading from PostgreSQL 8.3 has additional restrictions not present
|
||||
@ -478,7 +462,7 @@ psql --username postgres --file script.sql postgres
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
a user column is of data type tsvector
|
||||
a user column is of data type <type>tsvector</type>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
@ -489,7 +473,7 @@ psql --username postgres --file script.sql postgres
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
an index is of type hash or gin
|
||||
an index is of type hash or GIN
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
@ -522,7 +506,7 @@ psql --username postgres --file script.sql postgres
|
||||
|
||||
<para>
|
||||
<application>pg_upgrade</> does not support migration of databases
|
||||
containing these reg* system oid-referencing data types:
|
||||
containing these <type>reg*</> OID-referencing system data types:
|
||||
<type>regproc</>, <type>regprocedure</>, <type>regoper</>,
|
||||
<type>regoperator</>, <type>regclass</>, <type>regconfig</>, and
|
||||
<type>regdictionary</>. (<type>regtype</> can be migrated.)
|
||||
@ -544,9 +528,9 @@ psql --username postgres --file script.sql postgres
|
||||
If you want to use link mode and you don't want your old cluster
|
||||
to be modified when the new cluster is started, make a copy of the
|
||||
old cluster and migrate that with link mode. To make a valid copy
|
||||
of the old cluster, use <application>rsync</> to create a dirty
|
||||
of the old cluster, use <command>rsync</> to create a dirty
|
||||
copy of the old cluster while the server is running, then shut down
|
||||
the old server and run rsync again to update the copy with any
|
||||
the old server and run <command>rsync</> again to update the copy with any
|
||||
changes to make it consistent.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.10 2010/07/13 20:57:19 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/planstats.sgml,v 1.11 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="planner-stats-details">
|
||||
<title>How the Planner Uses Statistics</title>
|
||||
@ -428,7 +428,7 @@ rows = (outer_cardinality * inner_cardinality) * selectivity
|
||||
the unmodified size of <structname>tenk2</>. It might appear from
|
||||
inspection of the <command>EXPLAIN</> output that the estimate of
|
||||
join rows comes from 50 * 1, that is, the number of outer rows times
|
||||
the estimated number of rows obtained by each inner indexscan on
|
||||
the estimated number of rows obtained by each inner index scan on
|
||||
<structname>tenk2</>. But this is not the case: the join relation size
|
||||
is estimated before any particular join plan has been considered. If
|
||||
everything is working well then the two ways of estimating the join
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.87 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.88 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="plperl">
|
||||
<title>PL/Perl - Perl Procedural Language</title>
|
||||
@ -694,7 +694,7 @@ SELECT release_hosts_query();
|
||||
<listitem>
|
||||
<para>
|
||||
Return the unescaped binary data represented by the contents of the given string,
|
||||
which should be bytea encoded.
|
||||
which should be <type>bytea</type> encoded.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -708,7 +708,7 @@ SELECT release_hosts_query();
|
||||
<term><literal><function>encode_bytea</>(<replaceable>string</replaceable>)</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Return the bytea encoded form of the binary data contents of the given string.
|
||||
Return the <type>bytea</type> encoded form of the binary data contents of the given string.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.157 2010/08/09 02:25:05 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.158 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
|
||||
@ -1842,7 +1842,7 @@ END CASE;
|
||||
|
||||
<para>
|
||||
The searched form of <command>CASE</> provides conditional execution
|
||||
based on truth of boolean expressions. Each <literal>WHEN</> clause's
|
||||
based on truth of Boolean expressions. Each <literal>WHEN</> clause's
|
||||
<replaceable>boolean-expression</replaceable> is evaluated in turn,
|
||||
until one is found that yields <literal>true</>. Then the
|
||||
corresponding <replaceable>statements</replaceable> are executed, and
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_opfamily.sgml,v 1.7 2010/04/03 07:22:57 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_opfamily.sgml,v 1.8 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -240,7 +240,7 @@ ALTER OPERATOR FAMILY <replaceable>name</replaceable> USING <replaceable class="
|
||||
Before <productname>PostgreSQL</productname> 8.4, the <literal>OPERATOR</>
|
||||
clause could include a <literal>RECHECK</> option. This is no longer
|
||||
supported because whether an index operator is <quote>lossy</> is now
|
||||
determined on-the-fly at runtime. This allows efficient handling of
|
||||
determined on-the-fly at run time. This allows efficient handling of
|
||||
cases where an operator might or might not be lossy.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_role.sgml,v 1.17 2010/04/21 20:54:19 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/alter_role.sgml,v 1.18 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -86,7 +86,7 @@ ALTER ROLE <replaceable class="PARAMETER">name</replaceable> [ IN DATABASE <repl
|
||||
the named database. Whenever the role subsequently
|
||||
starts a new session, the specified value becomes the session
|
||||
default, overriding whatever setting is present in
|
||||
<filename>postgresql.conf</> or has been received from the postgres
|
||||
<filename>postgresql.conf</> or has been received from the <command>postgres</command>
|
||||
command line. This only happens at login time; executing
|
||||
<xref linkend="sql-set-role"> or
|
||||
<xref linkend="sql-set-session-authorization"> does not cause new
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.25 2010/04/03 07:22:58 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_opclass.sgml,v 1.26 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -250,7 +250,7 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
|
||||
Before <productname>PostgreSQL</productname> 8.4, the <literal>OPERATOR</>
|
||||
clause could include a <literal>RECHECK</> option. This is no longer
|
||||
supported because whether an index operator is <quote>lossy</> is now
|
||||
determined on-the-fly at runtime. This allows efficient handling of
|
||||
determined on-the-fly at run time. This allows efficient handling of
|
||||
cases where an operator might or might not be lossy.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.130 2010/07/26 01:43:52 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.131 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -512,7 +512,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE [ IF NOT EXISTS ] <repl
|
||||
The access method must support <literal>amgettuple</> (see <xref
|
||||
linkend="indexam">); at present this means <acronym>GIN</>
|
||||
cannot be used. Although it's allowed, there is little point in using
|
||||
btree or hash indexes with an exclusion constraint, because this
|
||||
B-tree or hash indexes with an exclusion constraint, because this
|
||||
does nothing that an ordinary unique constraint doesn't do better.
|
||||
So in practice the access method will always be <acronym>GiST</>.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.53 2010/04/03 07:23:00 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.54 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -74,7 +74,7 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Also, a trigger definition can specify a boolean <literal>WHEN</>
|
||||
Also, a trigger definition can specify a Boolean <literal>WHEN</>
|
||||
condition, which will be tested to see whether the trigger should
|
||||
be fired. In row-level triggers the <literal>WHEN</> condition can
|
||||
examine the old and/or new values of columns of the row. Statement-level
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.51 2010/06/22 16:19:36 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml,v 1.52 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -402,8 +402,8 @@ PostgreSQL documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default hostname or Unix-domain socket location for <xref
|
||||
linkend="app-psql"> (used by the -w option).
|
||||
Default host name or Unix-domain socket location for <xref
|
||||
linkend="app-psql"> (used by the <option>-w</option> option).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -413,7 +413,7 @@ PostgreSQL documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Default port number for <xref linkend="app-psql"> (used by the -w option).
|
||||
Default port number for <xref linkend="app-psql"> (used by the <option>-w</option> option).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v 1.83 2010/07/22 01:22:33 rhaas Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v 1.84 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -406,8 +406,8 @@ PostgreSQL documentation
|
||||
<para>
|
||||
Specifies the name of the database to connect to to dump global
|
||||
objects and discover what other databases should be dumped. If
|
||||
not specified, the <quote>postgres</quote> database will be used,
|
||||
and if that does not exist, <quote>template1</quote> will be used.
|
||||
not specified, the <literal>postgres</literal> database will be used,
|
||||
and if that does not exist, <literal>template1</literal> will be used.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.87 2010/05/15 18:11:07 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.88 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<refentry id="APP-PGRESTORE">
|
||||
<refmeta>
|
||||
@ -221,7 +221,7 @@
|
||||
create indexes, or create constraints — using multiple
|
||||
concurrent jobs. This option can dramatically reduce the time
|
||||
to restore a large database to a server running on a
|
||||
multi-processor machine.
|
||||
multiprocessor machine.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.249 2010/08/14 13:59:49 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.250 2010/08/17 04:37:21 petere Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -1043,7 +1043,7 @@ testdb=>
|
||||
If <replaceable class="parameter">pattern</replaceable> is
|
||||
specified, only those servers whose name matches the pattern
|
||||
are listed. If the form <literal>\des+</literal> is used, a
|
||||
full desription of each server is shown, including the
|
||||
full description of each server is shown, including the
|
||||
server's ACL, type, version, and options.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1706,8 +1706,8 @@ lo_import 152801
|
||||
<para>
|
||||
Prompts the user to set variable <replaceable
|
||||
class="parameter">name</>. An optional prompt, <replaceable
|
||||
class="parameter">text</>, can be specified. (For multi-word
|
||||
prompts, use single-quotes.)
|
||||
class="parameter">text</>, can be specified. (For multiword
|
||||
prompts, use single quotes.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -2836,7 +2836,7 @@ testdb=> <userinput>SELECT * FROM :"foo";</userinput>
|
||||
testdb=> <userinput>\set content `cat my_file.txt`</userinput>
|
||||
testdb=> <userinput>INSERT INTO my_table VALUES (:'content');</userinput>
|
||||
</programlisting>
|
||||
(Note that this still won't work if my_file.txt contains NUL bytes.
|
||||
(Note that this still won't work if <filename>my_file.txt</filename> contains NUL bytes.
|
||||
psql does not support embedded NUL bytes in variable values.)
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.67 2010/05/02 12:22:40 sriggs Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.68 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title>Regression Tests</title>
|
||||
@ -165,8 +165,8 @@ psql -h primary -c "CREATE DATABASE regression"
|
||||
psql -h primary -f src/test/regress/sql/hs_primary_setup.sql regression
|
||||
</screen>
|
||||
Now confirm that the default connection for the tester is the standby
|
||||
server under test and then run standbycheck from the regression
|
||||
directory.
|
||||
server under test and then run the <literal>standbycheck</> target from the regression
|
||||
directory:
|
||||
<screen>
|
||||
cd src/test/regress
|
||||
gmake standbycheck
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.48 2010/08/07 13:07:06 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.49 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="release-9-0">
|
||||
<title>Release 9.0</title>
|
||||
@ -99,7 +99,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
New and enhanced security features, including RADIUS authentication,
|
||||
LDAP authentication improvements, and the new checkpassword optional module
|
||||
LDAP authentication improvements, and the new <filename>checkpassword</> optional module
|
||||
for testing password strength.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -117,7 +117,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add <link linkend="pgupgrade"><filename>/contrib/pg_upgrade</></link>
|
||||
Add <link linkend="pgupgrade"><filename>contrib/pg_upgrade</></link>
|
||||
to support in-place upgrades from 8.3 or 8.4 to 9.0.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -149,14 +149,14 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
EXPLAIN plans are now available in JSON, XML and YAML format, and include
|
||||
<command>EXPLAIN</> plans are now available in JSON, XML, and YAML format, and include
|
||||
buffer utilization and other data not previously available.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
The HStore optional module has been improved with new functions and greater
|
||||
The <filename>hstore</> optional module has been improved with new functions and greater
|
||||
data capacity to make it a high-performance key-value store.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -205,7 +205,7 @@
|
||||
Remove server variable <varname>regex_flavor</>, which
|
||||
was defaulted to <link
|
||||
linkend="posix-syntax-details"><literal>advanced</></link>
|
||||
(e.g. Perl-regex compatible) for many years. (Tom Lane)
|
||||
(i.e., Perl compatible) for many years. (Tom Lane)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -554,7 +554,7 @@
|
||||
<para>
|
||||
This is particularly useful for finding
|
||||
<function>MAX()</>/<function>MIN()</> values in indexes that also
|
||||
contain NULLs.
|
||||
contain null values.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -581,7 +581,7 @@
|
||||
While the Genetic Query Optimizer (GEQO) still selects
|
||||
random plans, it now selects the same random plans for
|
||||
identical queries. You can modify <link
|
||||
linkend="guc-geqo-seed">geqo_seed</link> to randomize
|
||||
linkend="guc-geqo-seed"><varname>geqo_seed</></link> to randomize
|
||||
the starting value of the random plan generator.
|
||||
</para>
|
||||
|
||||
@ -766,7 +766,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now there is true multi-lingual support for PostgreSQL log messages
|
||||
Now there is true multilingual support for PostgreSQL log messages
|
||||
on Windows.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -827,7 +827,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add boolean variable <link
|
||||
Add Boolean variable <link
|
||||
linkend="guc-bonjour"><varname>bonjour</></link>, which
|
||||
controls whether a Bonjour-enabled binary advertises
|
||||
itself via <productname>Bonjour</> (Tom Lane)
|
||||
@ -840,7 +840,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add boolean variable <link
|
||||
Add Boolean variable <link
|
||||
linkend="guc-enable-material"><varname>enable_material</></link>, which
|
||||
controls the use of materialize nodes in the optimizer
|
||||
(Robert Haas)
|
||||
@ -1390,7 +1390,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add <literal>point_ops</> opclass for GiST (Teodor Sigaev)
|
||||
Add <literal>point_ops</> operator class for GiST (Teodor Sigaev)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1433,7 +1433,7 @@
|
||||
|
||||
<para>
|
||||
The variable <link
|
||||
linkend="guc-bytea-output">bytea_output</link> controls
|
||||
linkend="guc-bytea-output"><varname>bytea_output</></link> controls
|
||||
if hex (default) or octal escapes are used for <type>bytea</>
|
||||
output. (SWITCH DEFAULT FOR BETA? PETER) Libpq's
|
||||
<function>PQescapeByteaConn()</> now uses the hex format
|
||||
@ -1516,8 +1516,8 @@
|
||||
|
||||
<para>
|
||||
Previously, only <acronym>ASCII</> characters and single-byte
|
||||
encodings worked properly. Other multi-byte, non-<acronym>UTF-8</>
|
||||
encodings are still broken for case-insensitive regular expression
|
||||
encodings worked properly. Multibyte encodings other than <acronym>UTF-8</>
|
||||
are still broken for case-insensitive regular expression
|
||||
matching.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1868,14 +1868,14 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add server variable <link
|
||||
linkend="guc-plperl-on-init">plperl.on_init</link> to
|
||||
linkend="guc-plperl-on-init"><varname>plperl.on_init</></link> to
|
||||
specify a PL/Perl Perl initialization function (Tim
|
||||
Bunce)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<link
|
||||
linkend="guc-plperl-on-plperl-init">plperl.on_plperl_init</link>
|
||||
linkend="guc-plperl-on-plperl-init"><varname>plperl.on_plperl_init</></link>
|
||||
and <varname>plperl.on_plperlu_init</> are also available
|
||||
for trusted/untrusted-specific initialization.
|
||||
</para>
|
||||
@ -1904,7 +1904,7 @@
|
||||
|
||||
<para>
|
||||
This can be globally enabled with the server variable <link
|
||||
linkend="guc-plperl-use-strict">plperl.use_strict</link>.
|
||||
linkend="guc-plperl-use-strict"><varname>plperl.use_strict</></link>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1965,8 +1965,8 @@
|
||||
|
||||
<para>
|
||||
<type>Bytea</> values passed into PL/Python now are represented as
|
||||
binary, rather than the Postgres <type>bytea</> text format. Null
|
||||
bytes are now also output properly from PL/Python. <type>Boolean</>
|
||||
binary, rather than the PostgreSQL <type>bytea</> text format. Null
|
||||
bytes are now also output properly from PL/Python. <type>boolean</>
|
||||
and <type>numeric</> value passing in PL/Python was also improved.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2489,7 +2489,7 @@
|
||||
<para>
|
||||
These are similar to the existing <literal>all</>, <literal>install</>,
|
||||
and <literal>installcheck</> targets, but they build <acronym>HTML</>
|
||||
documentation, build and test <filename>/contrib</>, and test
|
||||
documentation, build and test <filename>contrib</>, and test
|
||||
server-side languages and <application>ecpg</>.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2582,7 +2582,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Allow multi-processor compilation using <productname>Microsoft Visual
|
||||
Allow multiprocessor compilation using <productname>Microsoft Visual
|
||||
C</> (Magnus Hagander)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2647,7 +2647,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Improve source code test coverage, including /contrib, PL/Python,
|
||||
Improve source code test coverage, including <filename>contrib</>, PL/Python,
|
||||
and PL/Perl (Peter Eisentraut, Andrew Dunstan)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2839,7 +2839,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add <link linkend="pgupgrade"><filename>/contrib/pg_upgrade</></link>
|
||||
Add <link linkend="pgupgrade"><filename>contrib/pg_upgrade</></link>
|
||||
to support in-place upgrades (Bruce Momjian)
|
||||
</para>
|
||||
|
||||
@ -2894,8 +2894,8 @@
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add multi-threaded option (<option>-j</>) to <link
|
||||
linkend="pgbench"><filename>/contrib/pgbench</></link>
|
||||
Add multithreaded option (<option>-j</>) to <link
|
||||
linkend="pgbench"><filename>contrib/pgbench</></link>
|
||||
(Itagaki Takahiro)
|
||||
</para>
|
||||
|
||||
@ -2908,7 +2908,7 @@
|
||||
<para>
|
||||
Add <command>\shell</> and <command>\setshell</> meta
|
||||
commands to <link
|
||||
linkend="pgbench"><filename>/contrib/pgbench</></link>
|
||||
linkend="pgbench"><filename>contrib/pgbench</></link>
|
||||
(Michael Paquier)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -2916,7 +2916,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
New features for <link
|
||||
linkend="dict-xsyn"><filename>/contrib/dict_xsyn</></link>
|
||||
linkend="dict-xsyn"><filename>contrib/dict_xsyn</></link>
|
||||
(Sergey Karpov)
|
||||
</para>
|
||||
|
||||
@ -2929,7 +2929,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add full text dictionary <link
|
||||
linkend="unaccent"><filename>/contrib/unaccent</></link>
|
||||
linkend="unaccent"><filename>contrib/unaccent</></link>
|
||||
(Teodor Sigaev)
|
||||
</para>
|
||||
|
||||
@ -2943,17 +2943,17 @@
|
||||
<para>
|
||||
Add <link
|
||||
linkend="CONTRIB-DBLINK-GET-NOTIFY"><function>dblink_get_notify()</></link>
|
||||
to <filename>/contrib/dblink</> (Marcus Kempe)
|
||||
to <filename>contrib/dblink</> (Marcus Kempe)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This allows async notifications in <productname>dblink</>.
|
||||
This allows asynchronous notifications in <productname>dblink</>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Improve <filename>/contrib/dblink</>s handling of dropped columns
|
||||
Improve <filename>contrib/dblink</>s handling of dropped columns
|
||||
(Tom Lane)
|
||||
</para>
|
||||
|
||||
@ -2967,22 +2967,22 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Greatly increase <link
|
||||
linkend="hstore"><filename>/contrib/hstore</></link>'s
|
||||
length limit and add btree and hash abilities so <literal>GROUP
|
||||
linkend="hstore"><filename>contrib/hstore</></link>'s
|
||||
length limit and add B-tree and hash abilities so <literal>GROUP
|
||||
BY</> and <literal>DISTINCT</> operations are possible
|
||||
(Andrew Gierth)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
New functions and operators were also added. These improvements
|
||||
make HStore a full-functional key-value store embedded in PostgreSQL.
|
||||
make hstore a full-functional key-value store embedded in PostgreSQL.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Add <link
|
||||
linkend="passwordcheck"><filename>/contrib/passwordcheck</></link>
|
||||
linkend="passwordcheck"><filename>contrib/passwordcheck</></link>
|
||||
which can check the strength of assigned passwords (Laurenz
|
||||
Albe)
|
||||
</para>
|
||||
@ -2996,7 +2996,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add <link
|
||||
linkend="pgarchivecleanup"><filename>/contrib/pg_archivecleanup</></link>
|
||||
linkend="pgarchivecleanup"><filename>contrib/pg_archivecleanup</></link>
|
||||
tool (Simon Riggs)
|
||||
</para>
|
||||
|
||||
@ -3009,7 +3009,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add query text to <link
|
||||
linkend="auto-explain"><filename>/contrib/auto_explain</></link>
|
||||
linkend="auto-explain"><filename>contrib/auto_explain</></link>
|
||||
output (Andrew Dunstan)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3017,7 +3017,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Add buffer access counters to <link
|
||||
linkend="pgstatstatements"><filename>/contrib/pg_stat_statements</></link>
|
||||
linkend="pgstatstatements"><filename>contrib/pg_stat_statements</></link>
|
||||
(Itagaki Takahiro)
|
||||
</para>
|
||||
</listitem>
|
||||
@ -3025,7 +3025,7 @@
|
||||
<listitem>
|
||||
<para>
|
||||
Update <link
|
||||
linkend="server-start"><filename>/contrib/start-scripts/linux</></link>
|
||||
linkend="server-start"><filename>contrib/start-scripts/linux</></link>
|
||||
to use <filename>/proc/self/oom_adj</> to disable the
|
||||
<link linkend="linux-memory-overcommit"><productname>Linux</>
|
||||
out-of-memory</link> (<acronym>OOM</>) killer (Alex
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.638 2010/03/21 22:12:27 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.639 2010/08/17 04:37:21 petere Exp $ -->
|
||||
<!--
|
||||
|
||||
Typical markup:
|
||||
@ -51,7 +51,7 @@ can be created without links to the main documentation. Don't use <xref>.
|
||||
A complete list of changes for each release can be obtained by
|
||||
viewing the <link linkend="cvs">CVS</link> logs for each release.
|
||||
The <ulink
|
||||
url="http://archives.postgresql.org/pgsql-committers/">pgsql-committers
|
||||
url="http://archives.postgresql.org/pgsql-committers/"><literal>pgsql-committers</literal>
|
||||
email list</ulink> records all source code changes as well. There is also
|
||||
a <ulink url="http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/">web
|
||||
interface</ulink> that shows changes to specific files.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/seg.sgml,v 1.8 2010/08/10 20:42:01 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/seg.sgml,v 1.9 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="seg">
|
||||
<title>seg</title>
|
||||
@ -237,7 +237,7 @@ test=> select '6.25 .. 6.50'::seg as "pH";
|
||||
<para>
|
||||
The <filename>seg</> module includes a GiST index operator class for
|
||||
<type>seg</> values.
|
||||
The operators supported by the GiST opclass are shown in <xref linkend="seg-gist-operators">.
|
||||
The operators supported by the GiST operator class are shown in <xref linkend="seg-gist-operators">.
|
||||
</para>
|
||||
|
||||
<table id="seg-gist-operators">
|
||||
@ -308,7 +308,7 @@ test=> select '6.25 .. 6.50'::seg as "pH";
|
||||
respectively called <literal>@</> and <literal>~</>. These names are still available, but are
|
||||
deprecated and will eventually be retired. Notice that the old names
|
||||
are reversed from the convention formerly followed by the core geometric
|
||||
datatypes!)
|
||||
data types!)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.67 2010/04/03 07:22:55 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/spi.sgml,v 1.68 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="spi">
|
||||
<title>Server Programming Interface</title>
|
||||
@ -987,7 +987,7 @@ SPIPlanPtr SPI_prepare_cursor(const char * <parameter>command</parameter>, int <
|
||||
<para>
|
||||
<function>SPI_prepare_cursor</function> is identical to
|
||||
<function>SPI_prepare</function>, except that it also allows specification
|
||||
of the planner's <quote>cursor options</> parameter. This is a bitmask
|
||||
of the planner's <quote>cursor options</> parameter. This is a bit mask
|
||||
having the values shown in <filename>nodes/parsenodes.h</filename>
|
||||
for the <structfield>options</> field of <structname>DeclareCursorStmt</>.
|
||||
<function>SPI_prepare</function> always takes the cursor options as zero.
|
||||
@ -1030,7 +1030,7 @@ SPIPlanPtr SPI_prepare_cursor(const char * <parameter>command</parameter>, int <
|
||||
<term><literal>int <parameter>cursorOptions</parameter></literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
integer bitmask of cursor options; zero produces default behavior
|
||||
integer bit mask of cursor options; zero produces default behavior
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1130,7 +1130,7 @@ SPIPlanPtr SPI_prepare_params(const char * <parameter>command</parameter>,
|
||||
<term><literal>int <parameter>cursorOptions</parameter></literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
integer bitmask of cursor options; zero produces default behavior
|
||||
integer bit mask of cursor options; zero produces default behavior
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -1925,7 +1925,7 @@ Portal SPI_cursor_open_with_args(const char *<parameter>name</parameter>,
|
||||
<term><literal>int <parameter>cursorOptions</parameter></literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
integer bitmask of cursor options; zero produces default behavior
|
||||
integer bit mask of cursor options; zero produces default behavior
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.33 2010/08/13 20:10:50 rhaas Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/storage.sgml,v 1.34 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="storage">
|
||||
|
||||
@ -821,7 +821,7 @@ data. Empty in ordinary tables.</entry>
|
||||
the next. Then make sure you have the right alignment. If the field is a
|
||||
fixed width field, then all the bytes are simply placed. If it's a
|
||||
variable length field (attlen = -1) then it's a bit more complicated.
|
||||
All variable-length datatypes share the common header structure
|
||||
All variable-length data types share the common header structure
|
||||
<type>struct varlena</type>, which includes the total length of the stored
|
||||
value and some flag bits. Depending on the flags, the data can be either
|
||||
inline or in a <acronym>TOAST</> table;
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/tablefunc.sgml,v 1.6 2010/08/10 20:42:01 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/tablefunc.sgml,v 1.7 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="tablefunc">
|
||||
<title>tablefunc</title>
|
||||
@ -46,7 +46,7 @@
|
||||
<entry>
|
||||
Produces a <quote>pivot table</> containing
|
||||
row names plus <replaceable>N</> value columns, where
|
||||
<replaceable>N</> is determined by the rowtype specified in the calling
|
||||
<replaceable>N</> is determined by the row type specified in the calling
|
||||
query
|
||||
</entry>
|
||||
</row>
|
||||
@ -219,9 +219,9 @@ SELECT * FROM crosstab('...') AS ct(row_name text, category_1 text, category_2 t
|
||||
|
||||
<para>
|
||||
The <literal>FROM</> clause must define the output as one
|
||||
<structfield>row_name</> column (of the same datatype as the first result
|
||||
<structfield>row_name</> column (of the same data type as the first result
|
||||
column of the SQL query) followed by N <structfield>value</> columns
|
||||
(all of the same datatype as the third result column of the SQL query).
|
||||
(all of the same data type as the third result column of the SQL query).
|
||||
You can set up as many output value columns as you wish. The names of the
|
||||
output columns are up to you.
|
||||
</para>
|
||||
@ -299,7 +299,7 @@ crosstab<replaceable>N</>(text sql)
|
||||
so that you need not write out column names and types in the calling
|
||||
<command>SELECT</> query. The <filename>tablefunc</> module includes
|
||||
<function>crosstab2</>, <function>crosstab3</>, and
|
||||
<function>crosstab4</>, whose output rowtypes are defined as
|
||||
<function>crosstab4</>, whose output row types are defined as
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.63 2010/04/03 07:22:56 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/trigger.sgml,v 1.64 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="triggers">
|
||||
<title>Triggers</title>
|
||||
@ -141,7 +141,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A trigger definition can also specify a boolean <literal>WHEN</>
|
||||
A trigger definition can also specify a Boolean <literal>WHEN</>
|
||||
condition, which will be tested to see whether the trigger should
|
||||
be fired. In row-level triggers the <literal>WHEN</> condition can
|
||||
examine the old and/or new values of columns of the row. (Statement-level
|
||||
|
@ -9,7 +9,7 @@
|
||||
<filename>unaccent</> removes accents (diacritic signs) from a lexeme.
|
||||
It's a filtering dictionary, that means its output is
|
||||
always passed to the next dictionary (if any), contrary to the standard
|
||||
behavior. Currently, it supports most important accents from european
|
||||
behavior. Currently, it supports most important accents from European
|
||||
languages.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/vacuumlo.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/vacuumlo.sgml,v 1.6 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="vacuumlo">
|
||||
<title>vacuumlo</title>
|
||||
@ -52,7 +52,7 @@ vacuumlo [options] database [database2 ... databaseN]
|
||||
<varlistentry>
|
||||
<term><option>-U</option> <replaceable>username</></term>
|
||||
<listitem>
|
||||
<para>Username to connect as.</para>
|
||||
<para>User name to connect as.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.71 2010/07/27 19:01:16 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.72 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Reliability and the Write-Ahead Log</title>
|
||||
@ -116,7 +116,7 @@
|
||||
write caches. At the drive level, disable write-back caching if the
|
||||
drive cannot guarantee the data will be written before shutdown.
|
||||
You can test for reliable I/O subsystem behavior using <ulink
|
||||
url="http://brad.livejournal.com/2116715.html">diskchecker.pl</ulink>.
|
||||
url="http://brad.livejournal.com/2116715.html"><filename>diskchecker.pl</filename></ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.66 2010/02/24 15:54:31 momjian Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.67 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="xindex">
|
||||
<title>Interfacing Extensions To Indexes</title>
|
||||
@ -416,39 +416,47 @@
|
||||
|
||||
<table tocentry="1" id="xindex-gin-support-table">
|
||||
<title>GIN Support Functions</title>
|
||||
<tgroup cols="2">
|
||||
<tgroup cols="3">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Function</entry>
|
||||
<entry>Description</entry>
|
||||
<entry>Support Number</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry><function>compare</></entry>
|
||||
<entry>
|
||||
compare - compare two keys and return an integer less than zero, zero,
|
||||
compare two keys and return an integer less than zero, zero,
|
||||
or greater than zero, indicating whether the first key is less than,
|
||||
equal to, or greater than the second
|
||||
</entry>
|
||||
<entry>1</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>extractValue - extract keys from a value to be indexed</entry>
|
||||
<entry><function>extractValue</></entry>
|
||||
<entry>extract keys from a value to be indexed</entry>
|
||||
<entry>2</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>extractQuery - extract keys from a query condition</entry>
|
||||
<entry><function>extractQuery</></entry>
|
||||
<entry>extract keys from a query condition</entry>
|
||||
<entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>consistent - determine whether value matches query condition</entry>
|
||||
<entry><function>consistent</></entry>
|
||||
<entry>determine whether value matches query condition</entry>
|
||||
<entry>4</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>comparePartial - (optional method) compare partial key from
|
||||
<entry><function>comparePartial</></entry>
|
||||
<entry>
|
||||
(optional method) compare partial key from
|
||||
query and key from index, and return an integer less than zero, zero,
|
||||
or greater than zero, indicating whether GIN should ignore this index
|
||||
entry, treat the entry as a match, or stop the index scan</entry>
|
||||
entry, treat the entry as a match, or stop the index scan
|
||||
</entry>
|
||||
<entry>5</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xml2.sgml,v 1.10 2010/08/10 20:42:01 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xml2.sgml,v 1.11 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="xml2">
|
||||
<title>xml2</title>
|
||||
@ -90,7 +90,7 @@ xpath_nodeset(document, query, toptag, itemtag) returns text
|
||||
<itemtag>Value 2....</itemtag>
|
||||
</toptag>
|
||||
</synopsis>
|
||||
If either toptag or itemtag is an empty string, the relevant tag is omitted.
|
||||
If either <literal>toptag</> or <literal>itemtag</> is an empty string, the relevant tag is omitted.
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
@ -102,7 +102,7 @@ xpath_nodeset(document, query) returns text
|
||||
</entry>
|
||||
<entry>
|
||||
<para>
|
||||
Like xpath_nodeset(document,query,toptag,itemtag) but result omits both tags.
|
||||
Like <function>xpath_nodeset(document, query, toptag, itemtag)</> but result omits both tags.
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
@ -114,7 +114,7 @@ xpath_nodeset(document, query, itemtag) returns text
|
||||
</entry>
|
||||
<entry>
|
||||
<para>
|
||||
Like xpath_nodeset(document,query,toptag,itemtag) but result omits toptag.
|
||||
Like <function>xpath_nodeset(document, query, toptag, itemtag)</> but result omits toptag.
|
||||
</para>
|
||||
</entry>
|
||||
</row>
|
||||
@ -295,7 +295,7 @@ WHERE t.author_id = p.person_id;
|
||||
may not be the same as the number of input documents. The first row
|
||||
returned contains the first result from each query, the second row the
|
||||
second result from each query. If one of the queries has fewer values
|
||||
than the others, NULLs will be returned instead.
|
||||
than the others, null values will be returned instead.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -337,8 +337,8 @@ WHERE id = 1 ORDER BY doc_num, line_num
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To get doc_num on every line, the solution is to use two invocations
|
||||
of xpath_table and join the results:
|
||||
To get <literal>doc_num</> on every line, the solution is to use two invocations
|
||||
of <function>xpath_table</> and join the results:
|
||||
|
||||
<programlisting>
|
||||
SELECT t.*,i.doc_num FROM
|
||||
@ -377,7 +377,7 @@ xslt_process(text document, text stylesheet, text paramlist) returns text
|
||||
|
||||
<para>
|
||||
This function applies the XSL stylesheet to the document and returns
|
||||
the transformed result. The paramlist is a list of parameter
|
||||
the transformed result. The <literal>paramlist</> is a list of parameter
|
||||
assignments to be used in the transformation, specified in the form
|
||||
<literal>a=1,b=2</>. Note that the
|
||||
parameter parsing is very simple-minded: parameter values cannot
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.43 2007/11/28 15:42:31 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.44 2010/08/17 04:37:21 petere Exp $ -->
|
||||
|
||||
<sect1 id="xoper">
|
||||
<title>User-Defined Operators</title>
|
||||
@ -435,7 +435,7 @@ table1.column1 OP table2.column2
|
||||
|
||||
<para>
|
||||
To be marked <literal>MERGES</literal>, the join operator must appear
|
||||
as an equality member of a btree index operator family.
|
||||
as an equality member of a <literal>btree</> index operator family.
|
||||
This is not enforced when you create
|
||||
the operator, since of course the referencing operator family couldn't
|
||||
exist yet. But the operator will not actually be used for merge joins
|
||||
@ -450,7 +450,7 @@ table1.column1 OP table2.column2
|
||||
if they are different) that appears in the same operator family.
|
||||
If this is not the case, planner errors might occur when the operator
|
||||
is used. Also, it is a good idea (but not strictly required) for
|
||||
a btree operator family that supports multiple data types to provide
|
||||
a <literal>btree</> operator family that supports multiple data types to provide
|
||||
equality operators for every combination of the data types; this
|
||||
allows better optimization.
|
||||
</para>
|
||||
|
Reference in New Issue
Block a user