Commit 66424a28 authored by Peter Eisentraut's avatar Peter Eisentraut

Fix indentation of verbatim block elements

Block elements with verbatim formatting (literallayout, programlisting,
screen, synopsis) should be aligned at column 0 independent of the surrounding
SGML, because whitespace is significant, and indenting them creates erratic
whitespace in the output.  The CSS stylesheets already take care of indenting
the output.

Assorted markup improvements to go along with it.
parent 984d56b8
<!-- $PostgreSQL: pgsql/doc/src/sgml/auto-explain.sgml,v 1.8 2010/04/03 07:22:52 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/auto-explain.sgml,v 1.9 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="auto-explain">
<title>auto_explain</title>
......@@ -19,9 +19,9 @@
The module provides no SQL-accessible functions. To use it, simply
load it into the server. You can load it into an individual session:
<programlisting>
<programlisting>
LOAD 'auto_explain';
</programlisting>
</programlisting>
(You must be superuser to do that.) More typical usage is to preload
it into all sessions by including <literal>auto_explain</> in
......@@ -163,32 +163,32 @@ LOAD 'auto_explain';
<xref linkend="guc-custom-variable-classes">. Typical usage might be:
</para>
<programlisting>
<programlisting>
# postgresql.conf
shared_preload_libraries = 'auto_explain'
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = '3s'
</programlisting>
</programlisting>
</sect2>
<sect2>
<title>Example</title>
<programlisting>
postgres=# LOAD 'auto_explain';
postgres=# SET auto_explain.log_min_duration = 0;
postgres=# SELECT count(*)
<programlisting>
postgres=# LOAD 'auto_explain';
postgres=# SET auto_explain.log_min_duration = 0;
postgres=# SELECT count(*)
FROM pg_class, pg_index
WHERE oid = indrelid AND indisunique;
</programlisting>
</programlisting>
<para>
This might produce log output such as:
</para>
<programlisting><![CDATA[
LOG: duration: 3.651 ms plan:
<screen><![CDATA[
LOG: duration: 3.651 ms plan:
Query Text: SELECT count(*)
FROM pg_class, pg_index
WHERE oid = indrelid AND indisunique;
......@@ -200,8 +200,7 @@ auto_explain.log_min_duration = '3s'
Buckets: 1024 Batches: 1 Memory Usage: 4kB
-> Seq Scan on pg_index (cost=0.00..3.02 rows=92 width=4) (actual time=0.008..3.187 rows=92 loops=1)
Filter: indisunique
]]>
</programlisting>
]]></screen>
</sect2>
<sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.4 2010/06/29 22:29:13 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="citext">
<title>citext</title>
......@@ -22,9 +22,9 @@
in <productname>PostgreSQL</> has been to use the <function>lower</>
function when comparing values, for example
<programlisting>
SELECT * FROM tab WHERE lower(col) = LOWER(?);
</programlisting>
<programlisting>
SELECT * FROM tab WHERE lower(col) = LOWER(?);
</programlisting>
</para>
<para>
......@@ -74,20 +74,20 @@
<para>
Here's a simple example of usage:
<programlisting>
CREATE TABLE users (
<programlisting>
CREATE TABLE users (
nick CITEXT PRIMARY KEY,
pass TEXT NOT NULL
);
);
INSERT INTO users VALUES ( 'larry', md5(random()::text) );
INSERT INTO users VALUES ( 'Tom', md5(random()::text) );
INSERT INTO users VALUES ( 'Damian', md5(random()::text) );
INSERT INTO users VALUES ( 'NEAL', md5(random()::text) );
INSERT INTO users VALUES ( 'Bj&oslash;rn', md5(random()::text) );
INSERT INTO users VALUES ( 'larry', md5(random()::text) );
INSERT INTO users VALUES ( 'Tom', md5(random()::text) );
INSERT INTO users VALUES ( 'Damian', md5(random()::text) );
INSERT INTO users VALUES ( 'NEAL', md5(random()::text) );
INSERT INTO users VALUES ( 'Bj&oslash;rn', md5(random()::text) );
SELECT * FROM users WHERE nick = 'Larry';
</programlisting>
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
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.139 2010/06/29 22:29:13 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.140 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="client-authentication">
<title>Client Authentication</title>
......@@ -1353,11 +1353,11 @@ omicron bryanh guest1
Since LDAP often uses commas and spaces to separate the different
parts of a DN, it is often necessary to use double-quoted parameter
values when configuring LDAP options, for example:
<programlisting>
ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
</programlisting>
</para>
</note>
<synopsis>
ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
</synopsis>
</sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.301 2010/07/27 19:01:16 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.302 2010/07/29 19:34:40 petere Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
......@@ -5808,29 +5808,20 @@ plruby.use_strict = true # generates error: unknown class name
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
is shown here:
</para>
<para>
LOG: LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
<screen>
LOG: LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(AccessShareLock)
</para>
<para>
LOG: GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
LOG: GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
wait(0) type(AccessShareLock)
</para>
<para>
LOG: UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
LOG: UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(AccessShareLock)
</para>
<para>
LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(INVALID)
</para>
<para>
</screen>
Details of the structure being dumped may be found in
src/include/storage/lock.h
</para>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.7 2009/12/08 20:08:30 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.8 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="cube">
<title>cube</title>
......@@ -98,47 +98,46 @@
<para>
The <filename>cube</> module includes a GiST index operator class for
<type>cube</> values.
The operators supported by the GiST opclass include:
The operators supported by the GiST opclass are shown in <xref linkend="cube-gist-operators">.
</para>
<itemizedlist>
<listitem>
<programlisting>
a = b Same as
</programlisting>
<para>
The cubes a and b are identical.
</para>
</listitem>
<listitem>
<programlisting>
a &amp;&amp; b Overlaps
</programlisting>
<para>
The cubes a and b overlap.
</para>
</listitem>
<listitem>
<programlisting>
a @&gt; b Contains
</programlisting>
<para>
The cube a contains the cube b.
</para>
</listitem>
<listitem>
<programlisting>
a &lt;@ b Contained in
</programlisting>
<para>
The cube a is contained in the cube b.
</para>
</listitem>
</itemizedlist>
<table id="cube-gist-operators">
<title>Cube GiST operators</title>
<tgroup cols="2">
<thead>
<row>
<entry>Operator</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>a = b</></entry>
<entry>The cubes a and b are identical.</entry>
</row>
<row>
<entry><literal>a &amp;&amp; b</></entry>
<entry>The cubes a and b overlap.</entry>
</row>
<row>
<entry><literal>a @&gt; b</></entry>
<entry>The cube a contains the cube b.</entry>
</row>
<row>
<entry><literal>a &lt;@ b</></entry>
<entry>The cube a is contained in the cube b.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
(Before PostgreSQL 8.2, the containment operators @&gt; and &lt;@ were
respectively called @ and ~. These names are still available, but are
(Before PostgreSQL 8.2, the containment operators <literal>@&gt;</> and <literal>&lt;@</> 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!)
......@@ -147,10 +146,28 @@ a &lt;@ b Contained in
<para>
The standard B-tree operators are also provided, for example
<programlisting>
[a, b] &lt; [c, d] Less than
[a, b] &gt; [c, d] Greater than
</programlisting>
<informaltable>
<tgroup cols="2">
<thead>
<row>
<entry>Operator</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>[a, b] &lt; [c, d]</literal></entry>
<entry>Less than</entry>
</row>
<row>
<entry><literal>[a, b] &gt; [c, d]</literal></entry>
<entry>Greater than</entry>
</row>
</tbody>
</tgroup>
</informaltable>
These operators do not make a lot of sense for any practical
purpose but sorting. These operators first compare (a) to (c),
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.254 2010/07/27 19:01:16 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.255 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="datatype">
<title>Data Types</title>
......@@ -1584,21 +1584,21 @@ SELECT E'\\xDEADBEEF';
<para>
The <type>interval</type> type has an additional option, which is
to restrict the set of stored fields by writing one of these phrases:
<programlisting>
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
YEAR TO MONTH
DAY TO HOUR
DAY TO MINUTE
DAY TO SECOND
HOUR TO MINUTE
HOUR TO SECOND
MINUTE TO SECOND
</programlisting>
<literallayout class="monospaced">
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
YEAR TO MONTH
DAY TO HOUR
DAY TO MINUTE
DAY TO SECOND
HOUR TO MINUTE
HOUR TO SECOND
MINUTE TO SECOND
</literallayout>
Note that if both <replaceable>fields</replaceable> and
<replaceable>p</replaceable> are specified, the
<replaceable>fields</replaceable> must include <literal>SECOND</>,
......@@ -3811,7 +3811,7 @@ SELECT to_tsvector('english', 'The Fat Rats');
of the operators:
<programlisting>
SELECT 'fat &amp; rat'::tsquery;
SELECT 'fat &amp; rat'::tsquery;
tsquery
---------------
'fat' &amp; 'rat'
......
This diff is collapsed.
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.93 2010/04/06 02:18:04 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.94 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="ddl">
<title>Data Definition</title>
......@@ -2520,7 +2520,7 @@ CREATE TABLE measurement_y2008m01 ( ) INHERITS (measurement);
just creating the partition tables as above, the table creation
script should really be:
<programlisting>
<programlisting>
CREATE TABLE measurement_y2006m02 (
CHECK ( logdate &gt;= DATE '2006-02-01' AND logdate &lt; DATE '2006-03-01' )
) INHERITS (measurement);
......@@ -2545,7 +2545,7 @@ CREATE TABLE measurement_y2008m01 (
<para>
We probably need indexes on the key columns too:
<programlisting>
<programlisting>
CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate);
CREATE INDEX measurement_y2006m03_logdate ON measurement_y2006m03 (logdate);
...
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/dict-xsyn.sgml,v 1.3 2009/08/05 18:06:49 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/dict-xsyn.sgml,v 1.4 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="dict-xsyn">
<title>dict_xsyn</title>
......@@ -64,9 +64,9 @@
<para>
Each line represents a group of synonyms for a single word, which is
given first on the line. Synonyms are separated by whitespace, thus:
<programlisting>
<programlisting>
word syn1 syn2 syn3
</programlisting>
</programlisting>
</para>
</listitem>
<listitem>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.100 2010/05/13 14:16:41 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.101 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="ecpg">
<title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
......@@ -2857,11 +2857,11 @@ struct sqlname
the dollar sign instead of the <literal>EXEC SQL</> primitive to introduce
embedded SQL commands.:
<programlisting>
$int j = 3;
$CONNECT TO :dbname;
$CREATE TABLE test(i INT PRIMARY KEY, j INT);
$INSERT INTO test(i, j) VALUES (7, :j);
$COMMIT;
$int j = 3;
$CONNECT TO :dbname;
$CREATE TABLE test(i INT PRIMARY KEY, j INT);
$INSERT INTO test(i, j) VALUES (7, :j);
$COMMIT;
</programlisting>
</para>
<para>
......@@ -2898,11 +2898,11 @@ struct sqlname
supported in Informix-mode without using <literal>typedef</literal>. In fact, in Informix-mode,
ECPG refuses to process source files that contain <literal>typedef sometype string;</literal>
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
string userid; /* this variable will contain trimmed data */
EXEC SQL END DECLARE SECTION;
EXEC SQL BEGIN DECLARE SECTION;
string userid; /* this variable will contain trimmed data */
EXEC SQL END DECLARE SECTION;
EXEC SQL FETCH MYCUR INTO :userid;
EXEC SQL FETCH MYCUR INTO :userid;
</programlisting>
</para>
</sect2>
......@@ -2918,8 +2918,8 @@ struct sqlname
This statement closes the current connection. In fact, this is a
synonym for ecpg's <literal>DISCONNECT CURRENT</>.:
<programlisting>
$CLOSE DATABASE; /* close the current connection */
EXEC SQL CLOSE DATABASE;
$CLOSE DATABASE; /* close the current connection */
EXEC SQL CLOSE DATABASE;
</programlisting>
</para>
</listitem>
......@@ -3083,15 +3083,15 @@ typedef struct sqlda_compat sqlda_t;
Pointer to the field data. The pointer is of <literal>char *</literal> type,
the data pointed by it is in a binary format. Example:
<programlisting>
int intval;
int intval;
switch (sqldata->sqlvar[i].sqltype)
{
switch (sqldata->sqlvar[i].sqltype)
{
case SQLINTEGER:
intval = *(int *)sqldata->sqlvar[i].sqldata;
break;
...
}
}
</programlisting>
</para>
</listitem>
......@@ -3106,7 +3106,7 @@ typedef struct sqlda_compat sqlda_t;
that the value for this field is non-NULL. Otherwise a valid pointer and <literal>sqlitype</literal>
has to be properly set. Example:
<programlisting>
if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
printf("value is NULL\n");
</programlisting>
</para>
......@@ -5208,13 +5208,13 @@ EXEC SQL UPDATE Tbl SET col = MYNUMBER;
<para>
Example:
<programlisting>
exec sql ifndef TZVAR;
exec sql SET TIMEZONE TO 'GMT';
exec sql elif TZNAME;
exec sql SET TIMEZONE TO TZNAME;
exec sql else;
exec sql SET TIMEZONE TO TZVAR;
exec sql endif;
EXEC SQL ifndef TZVAR;
EXEC SQL SET TIMEZONE TO 'GMT';
EXEC SQL elif TZNAME;
EXEC SQL SET TIMEZONE TO TZNAME;
EXEC SQL else;
EXEC SQL SET TIMEZONE TO TZVAR;
EXEC SQL endif;
</programlisting>
</para>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.521 2010/07/03 17:21:48 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.522 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="functions">
<title>Functions and Operators</title>
......@@ -8228,9 +8228,9 @@ SELECT xmlcomment('hello');
<primary>xmlconcat</primary>
</indexterm>
<synopsis>
<function>xmlconcat</function>(<replaceable>xml</replaceable><optional>, ...</optional>)
</synopsis>
<synopsis>
<function>xmlconcat</function>(<replaceable>xml</replaceable><optional>, ...</optional>)
</synopsis>
<para>
The function <function>xmlconcat</function> concatenates a list
......@@ -8286,8 +8286,8 @@ SELECT xmlconcat('<?xml version="1.1"?><foo/>', '<?xml version="1.1" standalone=
</indexterm>
<synopsis>
<function>xmlelement</function>(name <replaceable>name</replaceable> <optional>, xmlattributes(<replaceable>value</replaceable> <optional>AS <replaceable>attname</replaceable></optional> <optional>, ... </optional>)</optional> <optional><replaceable>, content, ...</replaceable></optional>)
</synopsis>
<function>xmlelement</function>(name <replaceable>name</replaceable> <optional>, xmlattributes(<replaceable>value</replaceable> <optional>AS <replaceable>attname</replaceable></optional> <optional>, ... </optional>)</optional> <optional><replaceable>, content, ...</replaceable></optional>)
</synopsis>
<para>
The <function>xmlelement</function> expression produces an XML
......@@ -8383,9 +8383,9 @@ SELECT xmlelement(name foo, xmlattributes('xyz' as bar),
<primary>xmlforest</primary>
</indexterm>
<synopsis>
<function>xmlforest</function>(<replaceable>content</replaceable> <optional>AS <replaceable>name</replaceable></optional> <optional>, ...</optional>)
</synopsis>
<synopsis>
<function>xmlforest</function>(<replaceable>content</replaceable> <optional>AS <replaceable>name</replaceable></optional> <optional>, ...</optional>)
</synopsis>
<para>
The <function>xmlforest</function> expression produces an XML
......@@ -8440,9 +8440,9 @@ WHERE table_schema = 'pg_catalog';
<primary>xmlpi</primary>
</indexterm>
<synopsis>
<function>xmlpi</function>(name <replaceable>target</replaceable> <optional>, <replaceable>content</replaceable></optional>)
</synopsis>
<synopsis>
<function>xmlpi</function>(name <replaceable>target</replaceable> <optional>, <replaceable>content</replaceable></optional>)
</synopsis>
<para>
The <function>xmlpi</function> expression creates an XML
......@@ -8469,9 +8469,9 @@ SELECT xmlpi(name php, 'echo "hello world";');
<primary>xmlroot</primary>
</indexterm>
<synopsis>
<function>xmlroot</function>(<replaceable>xml</replaceable>, version <replaceable>text</replaceable> | no value <optional>, standalone yes|no|no value</optional>)
</synopsis>
<synopsis>
<function>xmlroot</function>(<replaceable>xml</replaceable>, version <replaceable>text</replaceable> | no value <optional>, standalone yes|no|no value</optional>)
</synopsis>
<para>
The <function>xmlroot</function> expression alters the properties
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.5 2009/04/06 15:43:00 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="fuzzystrmatch">
<title>fuzzystrmatch</title>
......@@ -34,10 +34,10 @@
for working with Soundex codes:
</para>
<programlisting>
soundex(text) returns text
difference(text, text) returns int
</programlisting>
<synopsis>
soundex(text) returns text
difference(text, text) returns int
</synopsis>
<para>
The <function>soundex</> function converts a string to its Soundex code.
......@@ -53,7 +53,7 @@
Here are some usage examples:
</para>
<programlisting>
<programlisting>
SELECT soundex('hello world!');
SELECT soundex('Anne'), soundex('Ann'), difference('Anne', 'Ann');
......@@ -70,7 +70,7 @@ INSERT INTO s VALUES ('jack');
SELECT * FROM s WHERE soundex(nm) = soundex('john');
SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
</programlisting>
</programlisting>
</sect2>
<sect2>
......@@ -80,10 +80,10 @@ SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
This function calculates the Levenshtein distance between two strings:
</para>
<programlisting>
levenshtein(text source, text target, int ins_cost, int del_cost, int sub_cost) returns int
levenshtein(text source, text target) returns int
</programlisting>
<synopsis>
levenshtein(text source, text target, int ins_cost, int del_cost, int sub_cost) returns int
levenshtein(text source, text target) returns int
</synopsis>
<para>
Both <literal>source</literal> and <literal>target</literal> can be any
......@@ -97,7 +97,7 @@ SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
Examples:
</para>
<programlisting>
<screen>
test=# SELECT levenshtein('GUMBO', 'GAMBOL');
levenshtein
-------------
......@@ -109,7 +109,7 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
-------------
3
(1 row)
</programlisting>
</screen>
</sect2>
<sect2>
......@@ -125,9 +125,9 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
This function calculates the metaphone code of an input string:
</para>
<programlisting>
metaphone(text source, int max_output_length) returns text
</programlisting>
<synopsis>
metaphone(text source, int max_output_length) returns text
</synopsis>
<para>
<literal>source</literal> has to be a non-null string with a maximum of
......@@ -140,13 +140,13 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
Example:
</para>
<programlisting>
<screen>
test=# SELECT metaphone('GUMBO', 4);
metaphone
-----------
KM
(1 row)
</programlisting>
</screen>
</sect2>
<sect2>
......@@ -160,10 +160,10 @@ test=# SELECT metaphone('GUMBO', 4);
These functions compute the primary and alternate codes:
</para>
<programlisting>
dmetaphone(text source) returns text
dmetaphone_alt(text source) returns text
</programlisting>
<synopsis>
dmetaphone(text source) returns text
dmetaphone_alt(text source) returns text
</synopsis>
<para>
There is no length limit on the input strings.
......@@ -173,13 +173,13 @@ test=# SELECT metaphone('GUMBO', 4);
Example:
</para>
<programlisting>
<screen>
test=# select dmetaphone('gumbo');
dmetaphone
------------
KMP
(1 row)
</programlisting>
</screen>
</sect2>
</sect1>
<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.12 2010/07/02 20:36:49 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.13 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="hstore">
<title>hstore</title>
......@@ -24,11 +24,11 @@
includes zero or more <replaceable>key</> <literal>=&gt;</>
<replaceable>value</> pairs separated by commas. Some examples:
<programlisting>
k =&gt; v
foo =&gt; bar, baz =&gt; whatever
"1-a" =&gt; "anything at all"
</programlisting>
<synopsis>
k =&gt; v
foo =&gt; bar, baz =&gt; whatever
"1-a" =&gt; "anything at all"
</synopsis>
The order of the pairs is not significant (and may not be reproduced on
output). Whitespace between pairs or around the <literal>=&gt;</> sign is
......@@ -42,23 +42,23 @@
with duplicate keys, only one will be stored in the <type>hstore</> and
there is no guarantee as to which will be kept:
<programlisting>
% select 'a=&gt;1,a=&gt;2'::hstore;
<programlisting>
SELECT 'a=&gt;1,a=&gt;2'::hstore;
hstore
----------
"a"=&gt;"1"
</programlisting>
</programlisting>
</para>
<para>
A value (but not a key) can be an SQL <literal>NULL</>. For example:
<programlisting>
key =&gt; NULL
</programlisting>
<programlisting>
key =&gt; NULL
</programlisting>
The <literal>NULL</> keyword is case-insensitive. Double-quote the
<literal>NULL</> to treat it as the ordinary string "NULL".
<literal>NULL</> to treat it as the ordinary string <quote>NULL</quote>.
</para>
<note>
......@@ -421,11 +421,11 @@ b
<type>hstore</> has GiST and GIN index support for the <literal>@&gt;</>,
<literal>?</>, <literal>?&amp;</> and <literal>?|</> operators. For example:
</para>
<programlisting>
<programlisting>
CREATE INDEX hidx ON testhstore USING GIST (h);
CREATE INDEX hidx ON testhstore USING GIN (h);
</programlisting>
</programlisting>
<para>
<type>hstore</> also supports <type>btree</> or <type>hash</> indexes for
......@@ -436,11 +436,11 @@ CREATE INDEX hidx ON testhstore USING GIN (h);
may be useful for equivalence lookups. Create indexes for <literal>=</>
comparisons as follows:
</para>
<programlisting>
<programlisting>
CREATE INDEX hidx ON testhstore USING BTREE (h);
CREATE INDEX hidx ON testhstore USING HASH (h);
</programlisting>
</programlisting>
</sect2>
<sect2>
......@@ -448,22 +448,21 @@ CREATE INDEX hidx ON testhstore USING HASH (h);
<para>
Add a key, or update an existing key with a new value:
</para>
<programlisting>
<programlisting>
UPDATE tab SET h = h || ('c' =&gt; '3');
</programlisting>
</programlisting>
</para>
<para>
Delete a key:
</para>
<programlisting>
<programlisting>
UPDATE tab SET h = delete(h, 'k1');
</programlisting>
</programlisting>
</para>
<para>
Convert a <type>record</> to an <type>hstore</>:
</para>
<programlisting>
<programlisting>
CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');
......@@ -472,12 +471,12 @@ SELECT hstore(t) FROM test AS t;
---------------------------------------------
"col1"=&gt;"123", "col2"=&gt;"foo", "col3"=&gt;"bar"
(1 row)
</programlisting>
</programlisting>
</para>
<para>
Convert an <type>hstore</> to a predefined <type>record</> type:
</para>
<programlisting>
<programlisting>
CREATE TABLE test (col1 integer, col2 text, col3 text);
SELECT * FROM populate_record(null::test,
......@@ -486,12 +485,12 @@ SELECT * FROM populate_record(null::test,
------+------+------
456 | zzz |
(1 row)
</programlisting>
</programlisting>
</para>
<para>
Modify an existing record using the values from an <type>hstore</>:
</para>
<programlisting>
<programlisting>
CREATE TABLE test (col1 integer, col2 text, col3 text);
INSERT INTO test VALUES (123, 'foo', 'bar');
......@@ -500,7 +499,8 @@ SELECT (r).* FROM (SELECT t #= '"col3"=&gt;"baz"' AS r FROM test t) s;
------+------+------
123 | foo | baz
(1 row)
</programlisting>
</programlisting>
</para>
</sect2>
<sect2>
......@@ -515,22 +515,21 @@ SELECT (r).* FROM (SELECT t #= '"col3"=&gt;"baz"' AS r FROM test t) s;
<para>
Simple example:
</para>
<programlisting>
<programlisting>
SELECT * FROM each('aaa=&gt;bq, b=&gt;NULL, ""=&gt;1');
</programlisting>
</programlisting>
</para>
<para>
Using a table:
</para>
<programlisting>
<programlisting>
SELECT (each(h)).key, (each(h)).value INTO stat FROM testhstore;
</programlisting>
</programlisting>
</para>
<para>
Online statistics:
</para>
<programlisting>
<programlisting>
SELECT key, count(*) FROM
(SELECT (each(h)).key FROM testhstore) AS stat
GROUP BY key
......@@ -547,7 +546,8 @@ SELECT key, count(*) FROM
title | 190
org | 189
...................
</programlisting>
</programlisting>
</para>
</sect2>
<sect2>
......@@ -572,16 +572,16 @@ SELECT key, count(*) FROM
performance penalty when processing data that has not yet been modified by
the new code. It is possible to force an upgrade of all values in a table
column by doing an <literal>UPDATE</> statement as follows:
</para>
<programlisting>
<programlisting>
UPDATE tablename SET hstorecol = hstorecol || '';
</programlisting>
</programlisting>
</para>
<para>
Another way to do it is:
<programlisting>
<programlisting>
ALTER TABLE tablename ALTER hstorecol TYPE hstore USING hstorecol || '';
</programlisting>
</programlisting>
The <command>ALTER TABLE</> method requires an exclusive lock on the table,
but does not result in bloating the table with old row versions.
</para>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.33 2010/02/08 04:33:51 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.34 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="indexam">
<title>Index Access Method Interface Definition</title>
......@@ -1027,15 +1027,15 @@ amcostestimate (PlannerInfo *root,
Compute the index access cost. A generic estimator might do this:
<programlisting>
/*
/*
* Our generic assumption is that the index pages will be read
* sequentially, so they cost seq_page_cost each, not random_page_cost.
* Also, we charge for evaluation of the indexquals at each index row.
* All the costs are assumed to be paid incrementally during the scan.
*/
cost_qual_eval(&amp;index_qual_cost, indexQuals, root);
*indexStartupCost = index_qual_cost.startup;
*indexTotalCost = seq_page_cost * numIndexPages +
cost_qual_eval(&amp;index_qual_cost, indexQuals, root);
*indexStartupCost = index_qual_cost.startup;
*indexTotalCost = seq_page_cost * numIndexPages +
(cpu_index_tuple_cost + index_qual_cost.per_tuple) * numIndexTuples;
</programlisting>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.58 2010/07/27 19:01:16 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.59 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="install-win32">
<title>Installation from Source Code on <productname>Windows</productname></title>
......@@ -102,9 +102,9 @@
and then apply any changes from <filename>config.pl</filename>. For example,
to specify the location of your <productname>Python</productname> installation,
put the following in <filename>config.pl</filename>:
<screen>
$config->{python} = 'c:\python26';
</screen>
<programlisting>
$config->{python} = 'c:\python26';
</programlisting>
You only need to specify those parameters that are different from what's in
<filename>config_default.pl</filename>.
</para>
......@@ -114,9 +114,9 @@
<filename>buildenv.pl</filename> and put the required commands there. For
example, to add the path for bison when it's not in the PATH, create a file
containing:
<screen>
$ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
</screen>
<programlisting>
$ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
</programlisting>
</para>
<sect2>
......@@ -292,43 +292,31 @@
<para>
To build all of PostgreSQL in release configuration (the default), run the
command:
<screen>
<userinput>
build
</userinput>
</screen>
<screen>
<userinput>build</userinput>
</screen>
To build all of PostgreSQL in debug configuration, run the command:
<screen>
<userinput>
build DEBUG
</userinput>
</screen>
<screen>
<userinput>build DEBUG</userinput>
</screen>
To build just a single project, for example psql, run the commands:
<screen>
<userinput>
build psql
</userinput>
<userinput>
build DEBUG psql
</userinput>
</screen>
<screen>
<userinput>build psql</userinput>
<userinput>build DEBUG psql</userinput>
</screen>
To change the default build configuration to debug, put the following
in the <filename>buildenv.pl</filename> file:
<screen>
<userinput>
$ENV{CONFIG}="Debug";
</userinput>
</screen>
<programlisting>
$ENV{CONFIG}="Debug";
</programlisting>
</para>
<para>
It is also possible to build from inside the Visual Studio GUI. In this
case, you need to run:
<screen>
<userinput>
perl mkvcbuild.pl
</userinput>
</screen>
<screen>
<userinput>perl mkvcbuild.pl</userinput>
</screen>
from the command prompt, and then open the generated
<filename>pgsql.sln</filename> (in the root directory of the source tree)
in Visual Studio.
......@@ -354,11 +342,9 @@
<filename>debug</filename> or <filename>release</filename> directories. To
install these files using the standard layout, and also generate the files
required to initialize and use the database, run the command:
<screen>
<userinput>
install c:\destination\directory
</userinput>
</screen>
<screen>
<userinput>install c:\destination\directory</userinput>
</screen>
</para>
</sect2>
......@@ -373,28 +359,18 @@
the <filename>buildenv.pl</filename> file. To run the tests, run one of
the following commands from the <filename>src\tools\msvc</filename>
directory:
<screen>
<userinput>
vcregress check
</userinput>
<userinput>
vcregress installcheck
</userinput>
<userinput>
vcregress plcheck
</userinput>
<userinput>
vcregress contribcheck
</userinput>
</screen>
<screen>
<userinput>vcregress check</userinput>
<userinput>vcregress installcheck</userinput>
<userinput>vcregress plcheck</userinput>
<userinput>vcregress contribcheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
command line like:
<screen>
<userinput>
vcregress check serial
</userinput>
</screen>
<screen>
<userinput>vcregress check serial</userinput>
</screen>
For more information about the regression tests, see
<xref linkend="regress">.
......@@ -448,9 +424,9 @@
</variablelist>
Edit the <filename>buildenv.pl</filename> file, and add a variable for the
location of the root directory, for example:
<screen>
$ENV{DOCROOT}='c:\docbook';
</screen>
<programlisting>
$ENV{DOCROOT}='c:\docbook';
</programlisting>
To build the documentation, run the command
<filename>builddoc.bat</filename>. Note that this will actually run the
build twice, in order to generate the indexes. The generated HTML files
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/intagg.sgml,v 1.4 2008/11/14 19:58:45 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/intagg.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="intagg">
<title>intagg</title>
......@@ -44,24 +44,20 @@
<para>
Many database systems have the notion of a one to many table. Such a table
usually sits between two indexed tables, for example:
</para>
<programlisting>
<programlisting>
CREATE TABLE left (id INT PRIMARY KEY, ...);
CREATE TABLE right (id INT PRIMARY KEY, ...);
CREATE TABLE one_to_many(left INT REFERENCES left, right INT REFERENCES right);
</programlisting>
</programlisting>
<para>
It is typically used like this:
</para>
<programlisting>
SELECT right.* from right JOIN one_to_many ON (right.id = one_to_many.right)
<programlisting>
SELECT right.* from right JOIN one_to_many ON (right.id = one_to_many.right)
WHERE one_to_many.left = <replaceable>item</>;
</programlisting>
</programlisting>
<para>
This will return all the items in the right hand table for an entry
in the left hand table. This is a very common construct in SQL.
</para>
......@@ -74,35 +70,29 @@ CREATE TABLE one_to_many(left INT REFERENCES left, right INT REFERENCES right);
left hand entry. If you have a very dynamic system, there is not much you
can do. However, if you have some data which is fairly static, you can
create a summary table with the aggregator.
</para>
<programlisting>
CREATE TABLE summary as
<programlisting>
CREATE TABLE summary AS
SELECT left, int_array_aggregate(right) AS right
FROM one_to_many
GROUP BY left;
</programlisting>
</programlisting>
<para>
This will create a table with one row per left item, and an array
of right items. Now this is pretty useless without some way of using
the array; that's why there is an array enumerator. You can do
</para>
<programlisting>
<programlisting>
SELECT left, int_array_enum(right) FROM summary WHERE left = <replaceable>item</>;
</programlisting>
</programlisting>
<para>
The above query using <function>int_array_enum</> produces the same results
as
</para>
<programlisting>
<programlisting>
SELECT left, right FROM one_to_many WHERE left = <replaceable>item</>;
</programlisting>
</programlisting>
<para>
The difference is that the query against the summary table has to get
only one row from the table, whereas the direct query against
<structname>one_to_many</> must index scan and fetch a row for each entry.
......@@ -112,9 +102,8 @@ SELECT left, right FROM one_to_many WHERE left = <replaceable>item</>;
On one system, an <command>EXPLAIN</> showed a query with a cost of 8488 was
reduced to a cost of 329. The original query was a join involving the
<structname>one_to_many</> table, which was replaced by:
</para>
<programlisting>
<programlisting>
SELECT right, count(right) FROM
( SELECT left, int_array_enum(right) AS right
FROM summary JOIN (SELECT left FROM left_table WHERE left = <replaceable>item</>) AS lefts
......@@ -122,7 +111,8 @@ SELECT right, count(right) FROM
) AS list
GROUP BY right
ORDER BY count DESC;
</programlisting>
</programlisting>
</para>
</sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.10 2010/05/05 15:10:25 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.11 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="intarray">
<title>intarray</title>
......@@ -271,7 +271,7 @@
<sect2>
<title>Example</title>
<programlisting>
<programlisting>
-- a message can be in one or more <quote>sections</>
CREATE TABLE message (mid INT PRIMARY KEY, sections INT[], ...);
......@@ -286,7 +286,7 @@ SELECT message.mid FROM message WHERE message.sections @&gt; '{1,2}';
-- the same, using QUERY operator
SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
</programlisting>
</programlisting>
</sect2>
<sect2>
......@@ -297,13 +297,13 @@ SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
benchmark test suite. To run:
</para>
<programlisting>
cd .../bench
createdb TEST
psql TEST &lt; ../_int.sql
./create_test.pl | psql TEST
./bench.pl
</programlisting>
<programlisting>
cd .../bench
createdb TEST
psql TEST &lt; ../_int.sql
./create_test.pl | psql TEST
./bench.pl
</programlisting>
<para>
The <filename>bench.pl</> script has numerous options, which
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.5 2009/05/18 11:08:24 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="isn">
<title>isn</title>
......@@ -295,7 +295,7 @@
<sect2>
<title>Examples</title>
<programlisting>
<programlisting>
--Using the types directly:
SELECT isbn('978-0-393-04002-9');
SELECT isbn13('0901690546');
......@@ -333,7 +333,7 @@ UPDATE test SET id = make_valid(id) WHERE id = '2-205-00876-X!';
SELECT * FROM test;
SELECT isbn13(id) FROM test;
</programlisting>
</programlisting>
</sect2>
<sect2>
......@@ -342,24 +342,20 @@ SELECT isbn13(id) FROM test;
<para>
The information to implement this module was collected from
several sites, including:
</para>
<programlisting>
http://www.isbn-international.org/
http://www.issn.org/
http://www.ismn-international.org/
http://www.wikipedia.org/
</programlisting>
<itemizedlist>
<listitem><para><ulink url="http://www.isbn-international.org/"></ulink></para></listitem>
<listitem><para><ulink url="http://www.issn.org/"></ulink></para></listitem>
<listitem><para><ulink url="http://www.ismn-international.org/"></ulink></para></listitem>
<listitem><para><ulink url="http://www.wikipedia.org/"></ulink></para></listitem>
</itemizedlist>
<para>
The prefixes used for hyphenation were also compiled from:
</para>
<programlisting>
http://www.gs1.org/productssolutions/idkeys/support/prefix_list.html
http://www.isbn-international.org/en/identifiers.html
http://www.ismn-international.org/ranges.html
</programlisting>
<itemizedlist>
<listitem><para><ulink url="http://www.gs1.org/productssolutions/idkeys/support/prefix_list.html"></ulink></para></listitem>
<listitem><para><ulink url="http://www.isbn-international.org/en/identifiers.html"></ulink></para></listitem>
<listitem><para><ulink url="http://www.ismn-international.org/ranges.html"></ulink></para></listitem>
</itemizedlist>
<para>
Care was taken during the creation of the algorithms and they
were meticulously verified against the suggested algorithms
in the official ISBN, ISMN, ISSN User Manuals.
......
This diff is collapsed.
<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.3 2007/12/06 04:12:10 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.4 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="lo">
<title>lo</title>
......@@ -66,12 +66,12 @@
Here's a simple example of usage:
</para>
<programlisting>
CREATE TABLE image (title TEXT, raster lo);
<programlisting>
CREATE TABLE image (title TEXT, raster lo);
CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
FOR EACH ROW EXECUTE PROCEDURE lo_manage(raster);
</programlisting>
</programlisting>
<para>
For each column that will contain unique references to large objects,
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.4 2010/03/17 17:12:31 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="ltree">
<title>ltree</title>
......@@ -58,32 +58,32 @@
for matching <type>ltree</> values. A simple word matches that
label within a path. A star symbol (<literal>*</>) matches zero
or more labels. For example:
<programlisting>
<synopsis>
foo <lineannotation>Match the exact label path <literal>foo</></lineannotation>
*.foo.* <lineannotation>Match any label path containing the label <literal>foo</></lineannotation>
*.foo <lineannotation>Match any label path whose last label is <literal>foo</></lineannotation>
</programlisting>
</synopsis>
</para>
<para>
Star symbols can also be quantified to restrict how many labels
they can match:
<programlisting>
<synopsis>
*{<replaceable>n</>} <lineannotation>Match exactly <replaceable>n</> labels</lineannotation>
*{<replaceable>n</>,} <lineannotation>Match at least <replaceable>n</> labels</lineannotation>
*{<replaceable>n</>,<replaceable>m</>} <lineannotation>Match at least <replaceable>n</> but not more than <replaceable>m</> labels</lineannotation>
*{,<replaceable>m</>} <lineannotation>Match at most <replaceable>m</> labels &mdash; same as </lineannotation> *{0,<replaceable>m</>}
</programlisting>
</synopsis>
</para>
<para>
There are several modifiers that can be put at the end of a non-star
label in <type>lquery</> to make it match more than just the exact match:
<programlisting>
<synopsis>
@ <lineannotation>Match case-insensitively, for example <literal>a@</> matches <literal>A</></lineannotation>
* <lineannotation>Match any label with this prefix, for example <literal>foo*</> matches <literal>foobar</></lineannotation>
% <lineannotation>Match initial underscore-separated words</lineannotation>
</programlisting>
</synopsis>
The behavior of <literal>%</> is a bit complicated. It tries to match
words rather than the entire label. For example
<literal>foo_bar%</> matches <literal>foo_bar_baz</> but not
......@@ -102,10 +102,10 @@ foo <lineannotation>Match the exact label path <literal>foo</></lineanno
<para>
Here's an annotated example of <type>lquery</type>:
<programlisting>
Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
a. b. c. d. e.
</programlisting>
<programlisting>
Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
a. b. c. d. e.
</programlisting>
This query will match any label path that:
</para>
<orderedlist numeration='loweralpha'>
......@@ -154,9 +154,9 @@ foo <lineannotation>Match the exact label path <literal>foo</></lineanno
<para>
Here's an example <type>ltxtquery</type>:
<programlisting>
Europe &amp; Russia*@ &amp; !Transportation
</programlisting>
<programlisting>
Europe &amp; Russia*@ &amp; !Transportation
</programlisting>
This will match paths that contain the label <literal>Europe</literal> and
any label beginning with <literal>Russia</literal> (case-insensitive),
but not paths containing the label <literal>Transportation</literal>.
......@@ -504,9 +504,9 @@ foo <lineannotation>Match the exact label path <literal>foo</></lineanno
<para>
Example of creating such an index:
</para>
<programlisting>
CREATE INDEX path_gist_idx ON test USING GIST (path);
</programlisting>
<programlisting>
CREATE INDEX path_gist_idx ON test USING GIST (path);
</programlisting>
</listitem>
<listitem>
<para>
......@@ -517,9 +517,9 @@ foo <lineannotation>Match the exact label path <literal>foo</></lineanno
<para>
Example of creating such an index:
</para>
<programlisting>
CREATE INDEX path_gist_idx ON test USING GIST (array_path);
</programlisting>
<programlisting>
CREATE INDEX path_gist_idx ON test USING GIST (array_path);
</programlisting>
<para>
Note: This index type is lossy.
</para>
......@@ -535,7 +535,7 @@ foo <lineannotation>Match the exact label path <literal>foo</></lineanno
<filename>contrib/ltree/ltreetest.sql</> in the source distribution):
</para>
<programlisting>
<programlisting>
CREATE TABLE test (path ltree);
INSERT INTO test VALUES ('Top');
INSERT INTO test VALUES ('Top.Science');
......@@ -552,31 +552,29 @@ INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Galaxies');
INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Astronauts');
CREATE INDEX path_gist_idx ON test USING gist(path);
CREATE INDEX path_idx ON test USING btree(path);
</programlisting>
</programlisting>
<para>
Now, we have a table <structname>test</> populated with data describing
the hierarchy shown below:
</para>
<programlisting>
<literallayout class="monospaced">
Top
/ | \
Science Hobbies Collections
/ | \
Astronomy Amateurs_Astronomy Pictures
/ \ |
Astrophysics Cosmology Astronomy
Astrophysics Cosmology Astronomy
/ | \
Galaxies Stars Astronauts
</programlisting>
</literallayout>
<para>
We can do inheritance:
</para>
<programlisting>
ltreetest=# select path from test where path &lt;@ 'Top.Science';
<screen>
ltreetest=&gt; SELECT path FROM test WHERE path &lt;@ 'Top.Science';
path
------------------------------------
Top.Science
......@@ -584,14 +582,13 @@ ltreetest=# select path from test where path &lt;@ 'Top.Science';
Top.Science.Astronomy.Astrophysics
Top.Science.Astronomy.Cosmology
(4 rows)
</programlisting>
</screen>
</para>
<para>
Here are some examples of path matching:
</para>
<programlisting>
ltreetest=# select path from test where path ~ '*.Astronomy.*';
<screen>
ltreetest=&gt; SELECT path FROM test WHERE path ~ '*.Astronomy.*';
path
-----------------------------------------------
Top.Science.Astronomy
......@@ -603,20 +600,20 @@ ltreetest=# select path from test where path ~ '*.Astronomy.*';
Top.Collections.Pictures.Astronomy.Astronauts
(7 rows)
ltreetest=# select path from test where path ~ '*.!pictures@.*.Astronomy.*';
ltreetest=&gt; SELECT path FROM test WHERE path ~ '*.!pictures@.*.Astronomy.*';
path
------------------------------------
Top.Science.Astronomy
Top.Science.Astronomy.Astrophysics
Top.Science.Astronomy.Cosmology
(3 rows)
</programlisting>
</screen>
</para>
<para>
Here are some examples of full text search:
</para>
<programlisting>
ltreetest=# select path from test where path @ 'Astro*% &amp; !pictures@';
<screen>
ltreetest=&gt; SELECT path FROM test WHERE path @ 'Astro*% &amp; !pictures@';
path
------------------------------------
Top.Science.Astronomy
......@@ -625,45 +622,46 @@ ltreetest=# select path from test where path @ 'Astro*% &amp; !pictures@';
Top.Hobbies.Amateurs_Astronomy
(4 rows)
ltreetest=# select path from test where path @ 'Astro* &amp; !pictures@';
ltreetest=&gt; SELECT path FROM test WHERE path @ 'Astro* &amp; !pictures@';
path
------------------------------------
Top.Science.Astronomy
Top.Science.Astronomy.Astrophysics
Top.Science.Astronomy.Cosmology
(3 rows)
</programlisting>
</screen>
</para>
<para>
Path construction using functions:
</para>
<programlisting>
ltreetest=# select subpath(path,0,2)||'Space'||subpath(path,2) from test where path &lt;@ 'Top.Science.Astronomy';
<screen>
ltreetest=&gt; SELECT subpath(path,0,2)||'Space'||subpath(path,2) FROM test WHERE path &lt;@ 'Top.Science.Astronomy';
?column?
------------------------------------------
Top.Science.Space.Astronomy
Top.Science.Space.Astronomy.Astrophysics
Top.Science.Space.Astronomy.Cosmology
(3 rows)
</programlisting>
</screen>
</para>
<para>
We could simplify this by creating a SQL function that inserts a label
at a specified position in a path:
</para>
<programlisting>
<screen>
CREATE FUNCTION ins_label(ltree, int, text) RETURNS ltree
AS 'select subpath($1,0,$2) || $3 || subpath($1,$2);'
LANGUAGE SQL IMMUTABLE;
AS 'select subpath($1,0,$2) || $3 || subpath($1,$2);'
LANGUAGE SQL IMMUTABLE;
ltreetest=# select ins_label(path,2,'Space') from test where path &lt;@ 'Top.Science.Astronomy';
ltreetest=&gt; SELECT ins_label(path,2,'Space') FROM test WHERE path &lt;@ 'Top.Science.Astronomy';
ins_label
------------------------------------------
Top.Science.Space.Astronomy
Top.Science.Space.Astronomy.Astrophysics
Top.Science.Space.Astronomy.Cosmology
(3 rows)
</programlisting>
</screen>
</para>
</sect2>
<sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.80 2010/04/26 19:56:55 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.81 2010/07/29 19:34:40 petere Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
......@@ -1680,7 +1680,7 @@ Total time (ns) 2312105013
<para>
Add the probe definition to <filename>src/backend/utils/probes.d</>:
<programlisting>
probe transaction__start(LocalTransactionId);
probe transaction__start(LocalTransactionId);
</programlisting>
Note the use of the double underline in the probe name. In a DTrace
script using the probe, the double underline needs to be replaced with a
......@@ -1698,7 +1698,7 @@ Total time (ns) 2312105013
in the source code. In this case, it looks like the following:
<programlisting>
TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
</programlisting>
</para>
</step>
......@@ -1748,7 +1748,7 @@ Total time (ns) 2312105013
is actually enabled:
<programlisting>
if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
TRACE_POSTGRESQL_TRANSACTION_START(some_function(...));
</programlisting>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.8 2010/05/25 15:55:28 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.9 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="oid2name">
<title>oid2name</title>
......@@ -147,7 +147,7 @@
<sect2>
<title>Examples</title>
<programlisting>
<screen>
$ # what's in this database server, anyway?
$ oid2name
All databases:
......@@ -264,7 +264,7 @@ From database "alvherre":
Filenode Table Name
----------------------
155156 foo
</programlisting>
</screen>
</sect2>
<sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.6 2009/06/08 16:22:44 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.7 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pageinspect">
<title>pageinspect</title>
......@@ -62,15 +62,12 @@
<para>
A page image obtained with <function>get_raw_page</function> should be
passed as argument. For example:
</para>
<programlisting>
<screen>
test=# SELECT * FROM page_header(get_raw_page('pg_class', 0));
lsn | tli | flags | lower | upper | special | pagesize | version | prune_xid
-----------+-----+-------+-------+-------+---------+----------+---------+-----------
0/24A1B50 | 1 | 1 | 232 | 368 | 8192 | 8192 | 4 | 0
</programlisting>
<para>
</screen>
The returned columns correspond to the fields in the
<structname>PageHeaderData</> struct.
See <filename>src/include/storage/bufpage.h</> for details.
......@@ -93,11 +90,9 @@ test=# SELECT * FROM page_header(get_raw_page('pg_class', 0));
<para>
A heap page image obtained with <function>get_raw_page</function> should
be passed as argument. For example:
</para>
<programlisting>
<screen>
test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
</programlisting>
<para>
</screen>
See <filename>src/include/storage/itemid.h</> and
<filename>src/include/access/htup.h</> for explanations of the fields
returned.
......@@ -114,8 +109,7 @@ test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
<para>
<function>bt_metap</function> returns information about a btree
index's metapage. For example:
</para>
<programlisting>
<screen>
test=# SELECT * FROM bt_metap('pg_cast_oid_index');
-[ RECORD 1 ]-----
magic | 340322
......@@ -124,7 +118,8 @@ root | 1
level | 0
fastroot | 1
fastlevel | 0
</programlisting>
</screen>
</para>
</listitem>
</varlistentry>
......@@ -137,8 +132,7 @@ fastlevel | 0
<para>
<function>bt_page_stats</function> returns summary information about
single pages of btree indexes. For example:
</para>
<programlisting>
<screen>
test=# SELECT * FROM bt_page_stats('pg_cast_oid_index', 1);
-[ RECORD 1 ]-+-----
blkno | 1
......@@ -152,7 +146,8 @@ btpo_prev | 0
btpo_next | 0
btpo | 0
btpo_flags | 3
</programlisting>
</screen>
</para>
</listitem>
</varlistentry>
......@@ -165,8 +160,7 @@ btpo_flags | 3
<para>
<function>bt_page_items</function> returns detailed information about
all of the items on a btree index page. For example:
</para>
<programlisting>
<screen>
test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
itemoffset | ctid | itemlen | nulls | vars | data
------------+---------+---------+-------+------+-------------
......@@ -178,7 +172,8 @@ test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
6 | (0,6) | 12 | f | f | 28 27 00 00
7 | (0,7) | 12 | f | f | 29 27 00 00
8 | (0,8) | 12 | f | f | 2a 27 00 00
</programlisting>
</screen>
</para>
</listitem>
</varlistentry>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.1 2010/06/14 17:25:24 sriggs Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.2 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pgarchivecleanup">
<title>pg_archivecleanup</title>
......@@ -38,11 +38,9 @@
To configure a standby
server to use <application>pg_archivecleanup</>, put this into its
<filename>recovery.conf</filename> configuration file:
</para>
<programlisting>
<programlisting>
archive_cleanup_command = 'pg_archivecleanup <replaceable>archiveDir</> %r'
</programlisting>
<para>
</programlisting>
where <replaceable>archiveDir</> is the directory from which WAL segment
files should be restored.
</para>
......@@ -58,11 +56,9 @@ archive_cleanup_command = 'pg_archivecleanup <replaceable>archiveDir</> %r'
</para>
<para>
The full syntax of <application>pg_archivecleanup</>'s command line is
</para>
<synopsis>
<synopsis>
pg_archivecleanup <optional> <replaceable>option</> ... </optional> <replaceable>archivelocation</> <replaceable>restartwalfile</>
</synopsis>
<para>
</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
......@@ -70,15 +66,13 @@ pg_archivecleanup <optional> <replaceable>option</> ... </optional> <replaceable
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:
</para>
<programlisting>
<programlisting>
pg_archivecleanup -d archive 000000010000003700000010.00000020.backup
pg_archivecleanup: keep WAL files 000000010000003700000010 and later
pg_archivecleanup: removing "archive/00000001000000370000000F"
pg_archivecleanup: removing "archive/00000001000000370000000E"
</programlisting>
<para>
</programlisting>
<application>pg_archivecleanup</application> assumes that
<replaceable>archivelocation</> is a directory readable and writable by the
server-owning user.
......@@ -110,12 +104,10 @@ pg_archivecleanup: removing "archive/00000001000000370000000E"
<sect2>
<title>Examples</title>
<para>On Linux or Unix systems, you might use:</para>
<programlisting>
<para>On Linux or Unix systems, you might use:
<programlisting>
archive_cleanup_command = 'pg_archivecleanup -d .../archive %r 2>>cleanup.log'
</programlisting>
<para>
</programlisting>
where the archive directory is physically located on the standby server,
so that the <literal>archive_command</> is accessing it across NFS,
but the files are local to the standby.
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.16 2010/05/25 15:55:28 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.17 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pgbench">
<title>pgbench</title>
......@@ -22,7 +22,7 @@
<para>
Typical output from pgbench looks like:
<programlisting>
<screen>
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: simple
......@@ -32,7 +32,7 @@ number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 85.184871 (including connections establishing)
tps = 85.296346 (excluding connections establishing)
</programlisting>
</screen>
The first six lines report some of the most important parameter
settings. The next line reports the number of transactions completed
......@@ -53,9 +53,9 @@ tps = 85.296346 (excluding connections establishing)
step, but will instead need to do whatever setup your test needs.)
Initialization looks like:
<programlisting>
<programlisting>
pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbname</>
</programlisting>
</programlisting>
where <replaceable>dbname</> is the name of the already-created
database to test in. (You may also need <literal>-h</>,
......@@ -77,16 +77,14 @@ pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbn
<para>
At the default <quote>scale factor</> of 1, the tables initially
contain this many rows:
</para>
<programlisting>
<screen>
table # of rows
---------------------------------
pgbench_branches 1
pgbench_tellers 10
pgbench_accounts 100000
pgbench_history 0
</programlisting>
<para>
</screen>
You can (and, for most purposes, probably should) increase the number
of rows by using the <literal>-s</> (scale factor) option. The
<literal>-F</> (fillfactor) option might also be used at this point.
......@@ -96,9 +94,9 @@ pgbench_history 0
Once you have done the necessary setup, you can run your benchmark
with a command that doesn't include <literal>-i</>, that is
<programlisting>
<programlisting>
pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
</programlisting>
</programlisting>
In nearly all cases, you'll need some options to make a useful test.
The most important options are <literal>-c</> (number of clients),
......@@ -478,9 +476,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<para>
Example:
<programlisting>
<programlisting>
\set ntellers 10 * :scale
</programlisting>
</programlisting>
</para>
</listitem>
</varlistentry>
......@@ -501,9 +499,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<para>
Example:
<programlisting>
<programlisting>
\setrandom aid 1 :naccounts
</programlisting>
</programlisting>
</para>
</listitem>
</varlistentry>
......@@ -525,9 +523,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<para>
Example:
<programlisting>
<programlisting>
\sleep 10 ms
</programlisting>
</programlisting>
</para>
</listitem>
</varlistentry>
......@@ -554,9 +552,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<para>
Example:
<programlisting>
<programlisting>
\setshell variable_to_be_assigned command literal_argument :variable ::literal_starting_with_colon
</programlisting>
</programlisting>
</para>
</listitem>
</varlistentry>
......@@ -573,9 +571,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
<para>
Example:
<programlisting>
<programlisting>
\shell command literal_argument :variable ::literal_starting_with_colon
</programlisting>
</programlisting>
</para>
</listitem>
</varlistentry>
......@@ -585,7 +583,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
As an example, the full definition of the built-in TPC-B-like
transaction is:
<programlisting>
<programlisting>
\set nbranches :scale
\set ntellers 10 * :scale
\set naccounts 100000 * :scale
......@@ -600,7 +598,7 @@ UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
</programlisting>
</programlisting>
This script allows each iteration of the transaction to reference
different, randomly-chosen rows. (This example also shows why it's
......@@ -630,9 +628,9 @@ END;
<para>
The format of the log is:
<programlisting>
<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</>
</programlisting>
<synopsis>
<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</>
</synopsis>
where <replaceable>time</> is the elapsed transaction time in microseconds,
<replaceable>file_no</> identifies which script file was used
......@@ -646,12 +644,12 @@ END;
<para>
Here are example outputs:
<programlisting>
<screen>
0 199 2241 0 1175850568 995598
0 200 2465 0 1175850568 998079
0 201 2513 0 1175850569 608
0 202 2038 0 1175850569 2663
</programlisting>
</screen>
</para>
</sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbuffercache.sgml,v 2.6 2010/02/07 20:48:09 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbuffercache.sgml,v 2.7 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pgbuffercache">
<title>pg_buffercache</title>
......@@ -134,8 +134,8 @@
<sect2>
<title>Sample output</title>
<programlisting>
regression=# SELECT c.relname, count(*) AS buffers
<screen>
regression=# SELECT c.relname, count(*) AS buffers
FROM pg_buffercache b INNER JOIN pg_class c
ON b.relfilenode = pg_relation_filenode(c.oid) AND
b.reldatabase IN (0, (SELECT oid FROM pg_database
......@@ -143,8 +143,9 @@
GROUP BY c.relname
ORDER BY 2 DESC
LIMIT 10;
relname | buffers
---------------------------------+---------
---------------------------------+---------
tenk2 | 345
tenk1 | 141
pg_proc | 46
......@@ -155,8 +156,8 @@
pg_attribute_relid_attnam_index | 26
pg_depend | 22
pg_depend_reference_index | 20
(10 rows)
</programlisting>
(10 rows)
</screen>
</sect2>
<sect2>
......
This diff is collapsed.
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.6 2010/04/23 23:21:43 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.7 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pgfreespacemap">
<title>pg_freespacemap</title>
......@@ -75,7 +75,7 @@
<sect2>
<title>Sample output</title>
<programlisting>
<screen>
postgres=# SELECT * FROM pg_freespace('foo');
blkno | avail
-------+-------
......@@ -106,8 +106,7 @@ postgres=# SELECT * FROM pg_freespace('foo', 7);
--------------
1216
(1 row)
</programlisting>
</screen>
</sect2>
<sect2>
......
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgrowlocks.sgml,v 1.5 2009/05/18 11:08:24 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgrowlocks.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
<sect1 id="pgrowlocks">
<title>pgrowlocks</title>
......@@ -101,10 +101,10 @@ pgrowlocks(text) returns setof record
rows. If you want to take a look at the row contents at the same time, you
could do something like this:
<programlisting>
<programlisting>
SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
WHERE p.locked_row = a.ctid;
</programlisting>
</programlisting>
Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
query will be very inefficient.
......@@ -114,7 +114,7 @@ SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
<sect2>
<title>Sample output</title>
<programlisting>
<screen>
test=# SELECT * FROM pgrowlocks('t1');
locked_row | lock_type | locker | multi | xids | pids
------------+-----------+--------+-------+-----------+---------------
......@@ -123,7 +123,7 @@ test=# SELECT * FROM pgrowlocks('t1');
(0,3) | Exclusive | 804 | f | {804} | {29066}
(0,4) | Exclusive | 804 | f | {804} | {29066}
(4 rows)
</programlisting>
</screen>
</sect2>
<sect2>
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment