Add tools/find_gt_lt to find < and > in SGML source.
Lowercase some uppercase tags so tools is more reliable at finding problems.
This commit is contained in:
Bruce Momjian
parent
bdbfd343a2
commit
d08889aa8b
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.70 2004/12/27 19:19:23 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.71 2005/01/23 00:30:18 momjian Exp $
|
||||
-->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
|
|
@ -892,9 +892,9 @@ omicron bryanh guest1
|
|||
</para>
|
||||
|
||||
<para>
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
FATAL: no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb"
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
This is what you are most likely to get if you succeed in contacting
|
||||
the server, but it does not want to talk to you. As the message
|
||||
suggests, the server refused the connection request because it found
|
||||
|
|
@ -903,9 +903,9 @@ FATAL: no pg_hba.conf entry for host "123.123.123.123", user "andym", database
|
|||
</para>
|
||||
|
||||
<para>
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
FATAL: Password authentication failed for user "andym"
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
Messages like this indicate that you contacted the server, and it is
|
||||
willing to talk to you, but not until you pass the authorization
|
||||
method specified in the <filename>pg_hba.conf</filename> file. Check
|
||||
|
|
@ -915,16 +915,16 @@ FATAL: Password authentication failed for user "andym"
|
|||
</para>
|
||||
|
||||
<para>
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
FATAL: user "andym" does not exist
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
The indicated user name was not found.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
FATAL: database "testdb" does not exist
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
The database you are trying to connect to does not exist. Note that
|
||||
if you do not specify a database name, it defaults to the database
|
||||
user name, which may or may not be the right thing.
|
||||
|
|
|
|||
|
|
@ -1,35 +1,35 @@
|
|||
<Appendix Label="B" Id="contacts">
|
||||
<Title>Contacts</Title>
|
||||
<appendix label="B" id="contacts">
|
||||
<title>Contacts</title>
|
||||
|
||||
<!--
|
||||
<Para>
|
||||
<para>
|
||||
Support for <productname>PostgreSQL</productname> comes primarily from
|
||||
this printed documentation, the web-based mailing list archives,
|
||||
and the mailing lists themselves.
|
||||
</Para>
|
||||
</para>
|
||||
|
||||
<Sect1 id="mailing-list">
|
||||
<Title>Mailing Lists</Title>
|
||||
<sect1 id="mailing-list">
|
||||
<title>Mailing Lists</title>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
Refer to the introduction in this manual or to the
|
||||
<ulink url="http://www.postgresql.org"><productname>PostgreSQL</productname> web page</ulink>
|
||||
for subscription information to the no-cost mailing lists.
|
||||
</Para>
|
||||
</para>
|
||||
|
||||
<Sect1 id="people">
|
||||
<Title>People</Title>
|
||||
<sect1 id="people">
|
||||
<title>People</title>
|
||||
-->
|
||||
|
||||
<Para>
|
||||
<ItemizedList Mark="bullet" Spacing="compact">
|
||||
<ListItem>
|
||||
<Para>
|
||||
<ULink url="lockhart@fourpalms.org">Thomas Lockhart</ULink>
|
||||
<para>
|
||||
<itemizedlist mark="bullet" spacing="compact">
|
||||
<listitem>
|
||||
<para>
|
||||
<ulink url="lockhart@fourpalms.org">Thomas Lockhart</ulink>
|
||||
works on SQL standards compliance and documentation.
|
||||
</Para>
|
||||
</ListItem>
|
||||
</ItemizedList>
|
||||
</Para>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
</Appendix>
|
||||
</appendix>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.228 2005/01/17 02:29:23 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.229 2005/01/23 00:30:18 momjian Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
|
|
@ -249,7 +249,7 @@ su - postgres
|
|||
class="osname">Linux</>, <systemitem class="osname">NetBSD</>,
|
||||
<systemitem class="osname">Solaris</>), for other systems you
|
||||
can download an add-on package from here: <ulink
|
||||
url="http://developer.postgresql.org/~petere/bsd-gettext/" ></ulink>.
|
||||
url="http://developer.postgresql.org/~petere/bsd-gettext/"></ulink>.
|
||||
If you are using the <application>Gettext</> implementation in
|
||||
the <acronym>GNU</acronym> C library then you will additionally
|
||||
need the <productname>GNU Gettext</productname> package for some
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.49 2005/01/04 03:58:16 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.50 2005/01/23 00:30:31 momjian Exp $ -->
|
||||
|
||||
<refentry id="APP-PGRESTORE">
|
||||
<refmeta>
|
||||
|
|
@ -230,8 +230,8 @@
|
|||
<term><option>--use-list=<replaceable class="parameter">list-file</replaceable></option></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Restore elements in <REPLACEABLE
|
||||
CLASS="PARAMETER">list-file</REPLACEABLE> only, and in the
|
||||
Restore elements in <replaceable class="PARAMETER">
|
||||
list-file</replaceable> only, and in the
|
||||
order they appear in the file. Lines can be moved and may also
|
||||
be commented out by placing a <literal>;</literal> at the
|
||||
start of the line. (See below for examples.)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.323 2005/01/22 22:56:36 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.324 2005/01/23 00:30:18 momjian Exp $
|
||||
-->
|
||||
|
||||
<appendix id="release">
|
||||
|
|
@ -9777,31 +9777,31 @@ New Ports
|
|||
</para>
|
||||
<!--
|
||||
Contributors (appologies to any missed)
|
||||
* Kurt J. Lidl <lidl@va.pubnix.com>
|
||||
* Kurt J. Lidl <lidl@va.pubnix.com>
|
||||
(missed in first run, but no less important)
|
||||
* Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
|
||||
* Jason Wright <jason@shiloh.vnet.net>
|
||||
* Cees de Groot <C.deGroot@inter.NL.net>
|
||||
* Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
|
||||
* Jason Wright <jason@shiloh.vnet.net>
|
||||
* Cees de Groot <C.deGroot@inter.NL.net>
|
||||
* ernst.molitor@uni-bonn.de
|
||||
* michael.siebenborn@ae3.Hypo.DE (Michael Siebenborn (6929))
|
||||
* Brian E. Gallew <geek+@cmu.edu>
|
||||
* Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
|
||||
* Adam Sussman <myddryn@vidya.com>
|
||||
* Chris Dunlop <chris@onthe.net.au>
|
||||
* Marc G. Fournier <scrappy@ki.net>
|
||||
* Dan McGuirk <mcguirk@indirect.com>
|
||||
* Dr_George_D_Detlefsen <drgeorge@ilt.com>
|
||||
* Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
|
||||
* Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
* Randy Kunkee <kunkee@Starbase.NeoSoft.COM>
|
||||
* Rick Weldon <rick@wisetech.com>
|
||||
* Thomas van Reimersdahl <reimersd@dali.techinfo.rwth-aachen.de>
|
||||
* david bennett <dave@bensoft.com>
|
||||
* Brian E. Gallew <geek+@cmu.edu>
|
||||
* Vadim B. Mikheev <vadim@sable.krasnoyarsk.su>
|
||||
* Adam Sussman <myddryn@vidya.com>
|
||||
* Chris Dunlop <chris@onthe.net.au>
|
||||
* Marc G. Fournier <scrappy@ki.net>
|
||||
* Dan McGuirk <mcguirk@indirect.com>
|
||||
* Dr_George_D_Detlefsen <drgeorge@ilt.com>
|
||||
* Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
|
||||
* Massimo Dal Zotto <dz@cs.unitn.it>
|
||||
* Randy Kunkee <kunkee@Starbase.NeoSoft.COM>
|
||||
* Rick Weldon <rick@wisetech.com>
|
||||
* Thomas van Reimersdahl <reimersd@dali.techinfo.rwth-aachen.de>
|
||||
* david bennett <dave@bensoft.com>
|
||||
* ernst.molitor@uni-bonn.de
|
||||
* Julian Assange <proff@suburbia.net>
|
||||
* Bruce Momjian <pgman@candle.pha.pa.us>
|
||||
* Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
|
||||
* "Alistair G. Crooks" <azcb0@sde.uts.amdahl.com>
|
||||
* Julian Assange <proff@suburbia.net>
|
||||
* Bruce Momjian <pgman@candle.pha.pa.us>
|
||||
* Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu>
|
||||
* "Alistair G. Crooks" <azcb0@sde.uts.amdahl.com>
|
||||
-->
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,11 +1,11 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.302 2005/01/22 22:56:36 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.303 2005/01/23 00:30:18 momjian Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
<Title>Server Run-time Environment</Title>
|
||||
<chapter Id="runtime">
|
||||
<title>Server Run-time Environment</title>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
This chapter discusses how to set up and run the database server
|
||||
and its interactions with the operating system.
|
||||
</para>
|
||||
|
|
@ -447,7 +447,7 @@ psql: could not connect to server: No such file or directory
|
|||
</sect1>
|
||||
|
||||
<sect1 id="runtime-config">
|
||||
<Title>Run-time Configuration</Title>
|
||||
<title>Run-time Configuration</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>configuration</primary>
|
||||
|
|
@ -4981,7 +4981,7 @@ psql -h localhost -p 3333 template1
|
|||
|
||||
</sect1>
|
||||
|
||||
</Chapter>
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.37 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.38 2005/01/23 00:30:18 momjian Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xindex">
|
||||
|
|
@ -700,7 +700,7 @@ DEFAULT FOR TYPE int8 USING btree AS
|
|||
|
||||
<note>
|
||||
<para>
|
||||
In <ProductName>PostgreSQL</ProductName> versions before 7.4,
|
||||
In <productname>PostgreSQL</productname> versions before 7.4,
|
||||
sorting and grouping operations would implicitly use operators named
|
||||
<literal>=</>, <literal><</>, and <literal>></>. The new
|
||||
behavior of relying on default operator classes avoids having to make
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.32 2004/11/15 06:32:14 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.33 2005/01/23 00:30:18 momjian Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xoper">
|
||||
|
|
@ -10,7 +10,7 @@ $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.32 2004/11/15 06:32:14 neilc Exp
|
|||
<secondary>user-defined</secondary>
|
||||
</indexterm>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
Every operator is <quote>syntactic sugar</quote> for a call to an
|
||||
underlying function that does the real work; so you must
|
||||
first create the underlying function before you can create
|
||||
|
|
@ -19,9 +19,9 @@ $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.32 2004/11/15 06:32:14 neilc Exp
|
|||
that helps the query planner optimize queries that use the
|
||||
operator. The next section will be devoted to explaining
|
||||
that additional information.
|
||||
</Para>
|
||||
</para>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> supports left unary, right
|
||||
unary, and binary operators. Operators can be
|
||||
overloaded;<indexterm><primary>overloading</primary><secondary>operators</secondary></indexterm>
|
||||
|
|
@ -29,15 +29,15 @@ $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.32 2004/11/15 06:32:14 neilc Exp
|
|||
that have different numbers and types of operands. When a query is
|
||||
executed, the system determines the operator to call from the
|
||||
number and types of the provided operands.
|
||||
</Para>
|
||||
</para>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
Here is an example of creating an operator for adding two complex
|
||||
numbers. We assume we've already created the definition of type
|
||||
<type>complex</type> (see <xref linkend="xtypes">). First we need a
|
||||
function that does the work, then we can define the operator:
|
||||
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
CREATE FUNCTION complex_add(complex, complex)
|
||||
RETURNS complex
|
||||
AS '<replaceable>filename</replaceable>', 'complex_add'
|
||||
|
|
@ -49,10 +49,10 @@ CREATE OPERATOR + (
|
|||
procedure = complex_add,
|
||||
commutator = +
|
||||
);
|
||||
</ProgramListing>
|
||||
</Para>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
Now we could execute a query like this:
|
||||
|
||||
<screen>
|
||||
|
|
@ -63,9 +63,9 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
(5.2,6.05)
|
||||
(133.42,144.95)
|
||||
</screen>
|
||||
</Para>
|
||||
</para>
|
||||
|
||||
<Para>
|
||||
<para>
|
||||
We've shown how to create a binary operator here. To create unary
|
||||
operators, just omit one of <literal>leftarg</> (for left unary) or
|
||||
<literal>rightarg</> (for right unary). The <literal>procedure</>
|
||||
|
|
@ -74,14 +74,14 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
clause shown in the example is an optional hint to the query
|
||||
optimizer. Further details about <literal>commutator</> and other
|
||||
optimizer hints appear in the next section.
|
||||
</Para>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="xoper-optimization">
|
||||
<title>Operator Optimization Information</title>
|
||||
|
||||
<para>
|
||||
A <ProductName>PostgreSQL</ProductName> operator definition can include
|
||||
A <productname>PostgreSQL</productname> operator definition can include
|
||||
several optional clauses that tell the system useful things about how
|
||||
the operator behaves. These clauses should be provided whenever
|
||||
appropriate, because they can make for considerable speedups in execution
|
||||
|
|
@ -95,7 +95,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
|
||||
<para>
|
||||
Additional optimization clauses might be added in future versions of
|
||||
<ProductName>PostgreSQL</ProductName>. The ones described here are all
|
||||
<productname>PostgreSQL</productname>. The ones described here are all
|
||||
the ones that release &version; understands.
|
||||
</para>
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
<para>
|
||||
The left operand type of a commutable operator is the same as the
|
||||
right operand type of its commutator, and vice versa. So the name of
|
||||
the commutator operator is all that <ProductName>PostgreSQL</ProductName>
|
||||
the commutator operator is all that <productname>PostgreSQL</productname>
|
||||
needs to be given to look up the commutator, and that's all that needs to
|
||||
be provided in the <literal>COMMUTATOR</> clause.
|
||||
</para>
|
||||
|
|
@ -131,7 +131,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
index scan unless it can determine how to flip the clause around to
|
||||
<literal>tab2.y = tab1.x</>, because the index-scan machinery expects
|
||||
to see the indexed column on the left of the operator it is given.
|
||||
<ProductName>PostgreSQL</ProductName> will <emphasis>not</> simply
|
||||
<productname>PostgreSQL</productname> will <emphasis>not</> simply
|
||||
assume that this is a valid transformation — the creator of the
|
||||
<literal>=</> operator must specify that it is valid, by marking the
|
||||
operator with commutator information.
|
||||
|
|
@ -149,7 +149,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
<para>
|
||||
One way is to omit the <literal>COMMUTATOR</> clause in the first operator that
|
||||
you define, and then provide one in the second operator's definition.
|
||||
Since <ProductName>PostgreSQL</ProductName> knows that commutative
|
||||
Since <productname>PostgreSQL</productname> knows that commutative
|
||||
operators come in pairs, when it sees the second definition it will
|
||||
automatically go back and fill in the missing <literal>COMMUTATOR</> clause in
|
||||
the first definition.
|
||||
|
|
@ -159,12 +159,12 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
<listitem>
|
||||
<para>
|
||||
The other, more straightforward way is just to include <literal>COMMUTATOR</> clauses
|
||||
in both definitions. When <ProductName>PostgreSQL</ProductName> processes
|
||||
in both definitions. When <productname>PostgreSQL</productname> processes
|
||||
the first definition and realizes that <literal>COMMUTATOR</> refers to a nonexistent
|
||||
operator, the system will make a dummy entry for that operator in the
|
||||
system catalog. This dummy entry will have valid data only
|
||||
for the operator name, left and right operand types, and result type,
|
||||
since that's all that <ProductName>PostgreSQL</ProductName> can deduce
|
||||
since that's all that <productname>PostgreSQL</productname> can deduce
|
||||
at this point. The first operator's catalog entry will link to this
|
||||
dummy entry. Later, when you define the second operator, the system
|
||||
updates the dummy entry with the additional information from the second
|
||||
|
|
@ -225,9 +225,9 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
binary operators that return <type>boolean</>. The idea behind a restriction
|
||||
selectivity estimator is to guess what fraction of the rows in a
|
||||
table will satisfy a <literal>WHERE</literal>-clause condition of the form
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
column OP constant
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
for the current operator and a particular constant value.
|
||||
This assists the optimizer by
|
||||
giving it some idea of how many rows will be eliminated by <literal>WHERE</>
|
||||
|
|
@ -297,9 +297,9 @@ column OP constant
|
|||
binary operators that return <type>boolean</type>. The idea behind a join
|
||||
selectivity estimator is to guess what fraction of the rows in a
|
||||
pair of tables will satisfy a <literal>WHERE</>-clause condition of the form
|
||||
<ProgramListing>
|
||||
<programlisting>
|
||||
table1.column1 OP table2.column2
|
||||
</ProgramListing>
|
||||
</programlisting>
|
||||
for the current operator. As with the <literal>RESTRICT</literal> clause, this helps
|
||||
the optimizer very substantially by letting it figure out which
|
||||
of several possible join sequences is likely to take the least work.
|
||||
|
|
@ -496,7 +496,7 @@ table1.column1 OP table2.column2
|
|||
|
||||
<note>
|
||||
<para>
|
||||
In <ProductName>PostgreSQL</ProductName> versions before 7.3,
|
||||
In <productname>PostgreSQL</productname> versions before 7.3,
|
||||
the <literal>MERGES</> shorthand was not available: to make a
|
||||
merge-joinable operator one had to write both <literal>SORT1</> and
|
||||
<literal>SORT2</> explicitly. Also, the <literal>LTCMP</> and
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
document all new features
|
||||
update help output from inside the programs
|
||||
doc/src/sgml/ref manual pages
|
||||
convert any literal "<" and ">" characters
|
||||
convert any literal "<" and ">" characters, use tools/find_gt_lt
|
||||
|
||||
* Ports
|
||||
update config.guess and config.sub at the start of beta
|
||||
|
|
|
|||
|
|
@ -0,0 +1,2 @@
|
|||
grep '[^]a-z0-9"/!-]>' *.sgml ref/*.sgml
|
||||
grep '<[^]a-z0-9"/!-]' *.sgml ref/*.sgml
|
||||
Loading…
Reference in New Issue