Replace ASCII-quotes with proper markup.
This commit is contained in:
parent
9f990a73c1
commit
351a0c1736
|
@ -73,9 +73,9 @@ From that point on, the frontend process and the backend
|
|||
"superuser."
|
||||
Note that the <ProductName>Postgres</ProductName> superuser does not
|
||||
have to be a special user (e.g., a user named
|
||||
"postgres"), although many systems are installed that way.
|
||||
<literal>postgres</literal>), although many systems are installed that way.
|
||||
Furthermore, the <ProductName>Postgres</ProductName> superuser should
|
||||
definitely not be the Unix superuser, "root"! In any
|
||||
definitely not be the Unix superuser, <literal>root</literal>! In any
|
||||
case, all files relating to a database should belong to
|
||||
this <ProductName>Postgres</ProductName> superuser.
|
||||
</Para>
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.24 2001/09/10 05:46:41 ishii Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v 2.25 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="catalogs">
|
||||
|
@ -1737,7 +1737,7 @@
|
|||
to assume very much about what sort of statistics it stores. Only
|
||||
extremely general statistics (such as NULL-ness) are given dedicated
|
||||
columns in <structname>pg_statistic</structname>. Everything else
|
||||
is stored in "slots", which are groups of associated columns whose
|
||||
is stored in <quote>slots</quote>, which are groups of associated columns whose
|
||||
content is identified by a code number in one of the slot's columns.
|
||||
For more information see
|
||||
<filename>src/include/catalog/pg_statistic.h</filename>.
|
||||
|
@ -1803,7 +1803,7 @@
|
|||
<entry><type>int2</type></entry>
|
||||
<entry></entry>
|
||||
<entry>A code number indicating the kind of statistics stored in the Nth
|
||||
"slot" of the <structname>pg_statistic</structname> row.
|
||||
<quote>slot</quote> of the <structname>pg_statistic</structname> row.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
|
@ -1812,7 +1812,7 @@
|
|||
<entry><type>oid</type></entry>
|
||||
<entry>pg_operator.oid</entry>
|
||||
<entry>An operator used to derive the statistics stored in the
|
||||
Nth "slot". For example, a histogram slot would show the "<"
|
||||
Nth <quote>slot</quote>. For example, a histogram slot would show the <literal><</literal>
|
||||
operator that defines the sort order of the data.
|
||||
</entry>
|
||||
</row>
|
||||
|
@ -1822,7 +1822,7 @@
|
|||
<entry><type>float4[]</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Numerical statistics of the appropriate kind for the Nth
|
||||
"slot", or NULL if the slot kind does not involve numerical values.
|
||||
<quote>slot</quote>, or NULL if the slot kind does not involve numerical values.
|
||||
</entry>
|
||||
</row>
|
||||
|
||||
|
@ -1831,7 +1831,7 @@
|
|||
<entry><type>text[]</type></entry>
|
||||
<entry></entry>
|
||||
<entry>Column data values of the appropriate kind for the Nth
|
||||
"slot", or NULL if the slot kind does not store any data values.
|
||||
<quote>slot</quote>, or NULL if the slot kind does not store any data values.
|
||||
For datatype independence, all column data values are converted
|
||||
to external textual form and stored as TEXT datums.
|
||||
</entry>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.9 2001/09/09 23:52:12 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/charset.sgml,v 2.10 2001/09/13 15:55:22 petere Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
|
@ -396,7 +396,7 @@ perl: warning: Falling back to the standard locale ("C").
|
|||
</programlisting>
|
||||
|
||||
sets the default encoding to <literal>EUC_JP</literal> (Extended Unix Code for Japanese).
|
||||
Note that you can use "--encoding" instead of "-E" if you prefer
|
||||
Note that you can use <option>--encoding</option> instead of <option>-E</option> if you prefer
|
||||
to type longer option strings.
|
||||
If no -E or --encoding option is given, the encoding
|
||||
specified at configure time is used.
|
||||
|
@ -529,7 +529,7 @@ int PQsetClientEncoding(PGconn *<replaceable>conn</replaceable>, const char *<re
|
|||
int PQclientEncoding(const PGconn *<replaceable>conn</replaceable>)
|
||||
</programlisting>
|
||||
|
||||
Note that it returns the "encoding id," not the encoding symbol string
|
||||
Note that it returns the encoding id, not the encoding symbol string
|
||||
such as <literal>EUC_JP</literal>. To convert an encoding id to an encoding symbol, you
|
||||
can use:
|
||||
|
||||
|
@ -549,7 +549,7 @@ char *pg_encoding_to_char(int <replaceable>encoding_id</replaceable>)
|
|||
SET CLIENT_ENCODING TO 'encoding';
|
||||
</programlisting>
|
||||
|
||||
Also you can use SQL92 syntax "SET NAMES" for this purpose:
|
||||
Also you can use SQL92 syntax <literal>SET NAMES</literal> for this purpose:
|
||||
|
||||
<programlisting>
|
||||
SET NAMES 'encoding';
|
||||
|
@ -801,7 +801,7 @@ Sorry for my Eglish and C code, I'm not native :-)
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
A locale such as "<literal>ch</literal>" is correctly sorted
|
||||
A locale such as <literal>ch</literal> is correctly sorted
|
||||
only if your system
|
||||
supports that locale; older systems may not do so but new ones
|
||||
(e.g. RH6.0) do.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.15 2001/09/07 21:36:46 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/cvs.sgml,v 1.16 2001/09/13 15:55:22 petere Exp $
|
||||
CVS code repository
|
||||
Thomas Lockhart
|
||||
-->
|
||||
|
@ -206,8 +206,8 @@ $ cvs checkout -r REL6_4 tc
|
|||
|
||||
<para>
|
||||
When you tag more than one file with the same tag you can think
|
||||
about the tag as "a curve drawn through a matrix of filename vs.
|
||||
revision number". Say we have 5 files with the following revisions:
|
||||
about the tag as <quote>a curve drawn through a matrix of filename vs.
|
||||
revision number</quote>. Say we have 5 files with the following revisions:
|
||||
|
||||
<programlisting>
|
||||
file1 file2 file3 file4 file5
|
||||
|
@ -220,7 +220,7 @@ $ cvs checkout -r REL6_4 tc
|
|||
1.6
|
||||
</programlisting>
|
||||
|
||||
then the tag "<literal>TAG</literal>" will reference
|
||||
then the tag <literal>TAG</literal> will reference
|
||||
file1-1.2, file2-1.3, etc.
|
||||
|
||||
<note>
|
||||
|
@ -487,7 +487,7 @@ pgsql
|
|||
<para>
|
||||
<productname>CVSup</productname> was originally developed as a
|
||||
tool for distributing the <productname>FreeBSD</productname>
|
||||
source tree. It is available as a "port", and for those running
|
||||
source tree. It is available as a <quote>port</quote>, and for those running
|
||||
FreeBSD, if this is not sufficient to tell how to obtain and
|
||||
install it then please contribute a procedure here.
|
||||
</para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.62 2001/09/09 17:21:51 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.63 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="datatype">
|
||||
|
@ -1060,9 +1060,9 @@ SELECT b, char_length(b) FROM test2;
|
|||
The ordering of month and day in date input can be ambiguous, therefore a setting
|
||||
exists to specify how it should be interpreted in ambiguous cases. The command
|
||||
<literal>SET DateStyle TO 'US'</literal> or <literal>SET DateStyle TO 'NonEuropean'</literal>
|
||||
specifies the variant "month before day", the command
|
||||
specifies the variant <quote>month before day</quote>, the command
|
||||
<literal>SET DateStyle TO 'European'</literal> sets the variant
|
||||
"day before month". The <literal>ISO</literal> style
|
||||
<quote>day before month</quote>. The <literal>ISO</literal> style
|
||||
is the default but this default can be changed at compile time or at run time.
|
||||
</para>
|
||||
|
||||
|
@ -2129,8 +2129,9 @@ SELECT * FROM test1 WHERE a;
|
|||
</indexterm>
|
||||
|
||||
<para>
|
||||
Paths are represented by connected sets of points. Paths can be "open", where
|
||||
the first and last points in the set are not connected, and "closed",
|
||||
Paths are represented by connected sets of points. Paths can be
|
||||
<firstterm>open</firstterm>, where
|
||||
the first and last points in the set are not connected, and <firstterm>closed</firstterm>,
|
||||
where the first and last point are connected. Functions
|
||||
<function>popen(p)</function>
|
||||
and
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.20 2001/09/09 17:21:58 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.21 2001/09/13 15:55:22 petere Exp $
|
||||
Date/time details
|
||||
-->
|
||||
|
||||
|
@ -426,7 +426,7 @@ Date/time details
|
|||
interpreted as Australian timezone names. Without this option,
|
||||
<literal>CST</literal> and <literal>EST</literal> are taken as
|
||||
American timezone names, while <literal>SAT</literal> is interpreted as a
|
||||
noise word indicating "<literal>Saturday</literal>".
|
||||
noise word indicating <literal>Saturday</literal>.
|
||||
|
||||
<table tocentry="1">
|
||||
<title><productname>Postgres</productname> Australian Time Zones</title>
|
||||
|
@ -494,7 +494,7 @@ Date/time details
|
|||
<step>
|
||||
<para>
|
||||
If the token is numeric only, then it is either a single field
|
||||
or an ISO-8601 concatenated date (e.g. "19990113" for January 13, 1999)
|
||||
or an ISO-8601 concatenated date (e.g. <literal>19990113</literal> for January 13, 1999)
|
||||
or time (e.g. 141516 for 14:15:16).
|
||||
</para>
|
||||
</step>
|
||||
|
@ -553,7 +553,7 @@ Date/time details
|
|||
<para>
|
||||
If there are more than 4 digits,
|
||||
and if no other date fields have been previously read, then interpret
|
||||
as a "concatenated date" (e.g. <literal>19990118</literal>). 8
|
||||
as a <quote>concatenated date</quote> (e.g. <literal>19990118</literal>). 8
|
||||
and 6 digits are interpreted as year, month, and day, while 7
|
||||
and 5 digits are interpreted as year, day of year, respectively.
|
||||
</para>
|
||||
|
@ -658,7 +658,7 @@ Date/time details
|
|||
</para>
|
||||
|
||||
<para>
|
||||
"Julian Day" is different from "Julian Date".
|
||||
<quote>Julian Day</quote> is different from <quote>Julian Date</quote>.
|
||||
|
||||
The Julian calendar was introduced by Julius Caesar in 45 BC. It was
|
||||
in common use until the 1582, when countries started changing to the
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.32 2001/04/20 15:52:33 thomas Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.33 2001/09/13 15:55:22 petere Exp $ -->
|
||||
|
||||
<appendix label="DG2" id="docguide">
|
||||
<title>Documentation</title>
|
||||
|
@ -626,7 +626,7 @@ gmake man
|
|||
<acronym>SGML</acronym> source code to <acronym>RTF</acronym>, then
|
||||
importing into <productname>ApplixWare-4.4.1</productname>.
|
||||
After a little cleanup (see the following
|
||||
section) the output is "printed" to a postscript file.
|
||||
section) the output is <quote>printed</quote> to a postscript file.
|
||||
</para>
|
||||
|
||||
<!--
|
||||
|
@ -828,7 +828,7 @@ exit
|
|||
<para>
|
||||
Not all documents have figures.
|
||||
You can grep the <acronym>SGML</acronym> source files for
|
||||
the string "<literal>graphic</literal>" to identify those parts of the
|
||||
the string <literal>graphic</literal> to identify those parts of the
|
||||
documentation that may have figures. A few figures are replicated in
|
||||
various parts of the documentation.
|
||||
</para>
|
||||
|
@ -866,7 +866,7 @@ exit
|
|||
|
||||
<step performance="required">
|
||||
<para>
|
||||
"Print" the document
|
||||
<quote>Print</quote> the document
|
||||
to a file in Postscript format.
|
||||
</para>
|
||||
</step>
|
||||
|
@ -987,14 +987,14 @@ exit
|
|||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Export the result as "ASCII Layout".
|
||||
Export the result as <literal>ASCII Layout</literal>.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Using emacs or vi, clean up the tabular information in
|
||||
<filename>INSTALL</filename>. Remove the "mailto"
|
||||
<filename>INSTALL</filename>. Remove the <literal>mailto</literal>
|
||||
<acronym>URLs</acronym> for the porting contributors to shrink
|
||||
the column heights.
|
||||
</para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.22 2001/09/10 21:58:46 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.23 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="ecpg">
|
||||
|
@ -114,7 +114,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.22 2001/09/10 21:58:46 petere
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The library has some methods that are "hidden" but may prove
|
||||
The library has some methods that are <quote>hidden</quote> but may prove
|
||||
useful.
|
||||
|
||||
<itemizedlist>
|
||||
|
@ -316,7 +316,7 @@ struct sqlca
|
|||
<para>
|
||||
This means the host variable is of type <type>bool</type> and
|
||||
the field in the <productname>Postgres</productname> database
|
||||
is neither 't' nor 'f'.
|
||||
is neither <literal>'t'</> nor <literal>'f'</>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -393,7 +393,7 @@ struct sqlca
|
|||
<term><computeroutput>100, Data not found line %d.</computeroutput></term>
|
||||
<listitem>
|
||||
<para>
|
||||
This is a "normal" error that tells you that what you are querying cannot
|
||||
This is a <quote>normal</quote> error that tells you that what you are querying cannot
|
||||
be found or you are at the end of the cursor.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -421,7 +421,7 @@ struct sqlca
|
|||
<para>
|
||||
Oracle version 7.0 on <systemitem class="osname">AIX</> 3 uses OS-supported locks in shared
|
||||
memory that allow an application designer to link an application
|
||||
in a "single tasking" way. Instead of starting one client
|
||||
in a <quote>single tasking</quote> way. Instead of starting one client
|
||||
process per application process, both the database part and the
|
||||
application part run in the same process. In later versions of
|
||||
Oracle this is no longer supported.
|
||||
|
@ -555,7 +555,7 @@ struct sqlca
|
|||
<term>message 'no data found'</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The error message for "no data" in:
|
||||
The error message for <quote>no data</quote> in:
|
||||
<programlisting>
|
||||
exec sql insert select from statement
|
||||
</programlisting>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.11 2001/09/10 21:58:46 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.12 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="extend">
|
||||
|
@ -67,7 +67,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.11 2001/09/10 21:58:46 pete
|
|||
or shared library) that implements a new type or function
|
||||
and <productname>Postgres</productname> will load it as required. Code written
|
||||
in <acronym>SQL</acronym> are even more trivial to add to the server.
|
||||
This ability to modify its operation "on the fly" makes
|
||||
This ability to modify its operation <quote>on the fly</quote> makes
|
||||
<productname>Postgres</productname> uniquely suited for rapid prototyping of new
|
||||
applications and storage structures.
|
||||
</para>
|
||||
|
@ -82,7 +82,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.11 2001/09/10 21:58:46 pete
|
|||
Types are divided into base types and composite types.
|
||||
Base types are those, like <firstterm>int4</firstterm>, that are implemented
|
||||
in a language such as <productname>C</productname>. They generally correspond to
|
||||
what are often known as "abstract data types"; <productname>Postgres</productname>
|
||||
what are often known as <firstterm>abstract data types</firstterm>; <productname>Postgres</productname>
|
||||
can only operate on such types through methods provided
|
||||
by the user and only understands the behavior of such
|
||||
types to the extent that the user describes them.
|
||||
|
@ -94,7 +94,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.11 2001/09/10 21:58:46 pete
|
|||
<productname>Postgres</productname> stores these types
|
||||
in only one way (within the
|
||||
file that stores all rows of a table) but the
|
||||
user can "look inside" at the attributes of these types
|
||||
user can <quote>look inside</quote> at the attributes of these types
|
||||
from the query language and optimize their retrieval by
|
||||
(for example) defining indexes on the attributes.
|
||||
<productname>Postgres</productname> base types are further
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.17 2001/05/17 21:50:15 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.18 2001/09/13 15:55:22 petere Exp $
|
||||
Genetic Optimizer
|
||||
-->
|
||||
|
||||
|
@ -114,7 +114,7 @@ Genetic Optimizer
|
|||
</para>
|
||||
|
||||
<para>
|
||||
According to the "comp.ai.genetic" <acronym>FAQ</acronym> it cannot be stressed too
|
||||
According to the <systemitem class="resource">comp.ai.genetic</> <acronym>FAQ</acronym> it cannot be stressed too
|
||||
strongly that a <acronym>GA</acronym> is not a pure random search for a solution to a
|
||||
problem. A <acronym>GA</acronym> uses stochastic processes, but the result is distinctly
|
||||
non-random (better than random).
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.15 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="history">
|
||||
|
@ -40,7 +40,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 pet
|
|||
|
||||
<para>
|
||||
<productname>Postgres</productname> has undergone several major releases since
|
||||
then. The first "demoware" system became operational
|
||||
then. The first <quote>demoware</quote> system became operational
|
||||
in 1987 and was shown at the 1988 <acronym>ACM-SIGMOD</acronym>
|
||||
Conference. We released Version 1, described in
|
||||
<xref endterm="STON90a-full" linkend="STON90a">,
|
||||
|
@ -186,7 +186,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 pet
|
|||
<title><productname>PostgreSQL</productname></title>
|
||||
|
||||
<para>
|
||||
By 1996, it became clear that the name "Postgres95" would
|
||||
By 1996, it became clear that the name <quote>Postgres95</quote> would
|
||||
not stand the test of time. We chose a new name,
|
||||
<productname>PostgreSQL</productname>, to reflect the relationship
|
||||
between the original <productname>Postgres</productname> and the more
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.8 2001/09/10 21:58:46 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.9 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="indexcost">
|
||||
|
@ -170,7 +170,7 @@ amcostestimate (Query *root,
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The "start-up cost" is the part of the total scan cost that must be expended
|
||||
The <quote>start-up cost</quote> is the part of the total scan cost that must be expended
|
||||
before we can begin to fetch the first tuple. For most indexes this can
|
||||
be taken as zero, but an index type with a high start-up cost might want
|
||||
to set it nonzero.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.15 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="inherit">
|
||||
|
@ -153,13 +153,13 @@ SELECT name, altitude
|
|||
In previous versions of <productname>Postgres</productname>, the
|
||||
default was not to get access to child tables. This was found to
|
||||
be error prone and is also in violation of SQL99. Under the old
|
||||
syntax, to get the sub-tables you append "*" to the table name.
|
||||
syntax, to get the sub-tables you append <literal>*</literal> to the table name.
|
||||
For example
|
||||
<programlisting>
|
||||
SELECT * from cities*;
|
||||
</programlisting>
|
||||
You can still explicitly specify scanning child tables by appending
|
||||
"*", as well as explicitly specify not scanning child tables by
|
||||
<literal>*</literal>, as well as explicitly specify not scanning child tables by
|
||||
writing <quote>ONLY</quote>. But beginning in version 7.1, the default
|
||||
behavior for an undecorated table name is to scan its child tables
|
||||
too, whereas before the default was not to do so. To get the old
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.24 2001/09/12 15:55:00 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.25 2001/09/13 15:55:22 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="jdbc">
|
||||
|
@ -2372,7 +2372,7 @@ maidast | 2610132
|
|||
<para>
|
||||
The only time you would access this class, is to use the create()
|
||||
methods. These are not used by the driver, but issue one or more
|
||||
"create table" statements to the database, based on a Java Object
|
||||
<command>CREATE TABLE</command> statements to the database, based on a Java Object
|
||||
or Class that you want to serialize.
|
||||
</para>
|
||||
|
||||
|
@ -2865,7 +2865,7 @@ Methods
|
|||
String original)
|
||||
|
||||
Encrypt a password given the clear-text password and a
|
||||
"salt".
|
||||
<quote>salt</quote>.
|
||||
|
||||
Parameters:
|
||||
salt - A two-character string representing the salt
|
||||
|
|
|
@ -921,7 +921,7 @@ given chunk of code for each tuple in the result.
|
|||
<TITLE>Usage
|
||||
</TITLE>
|
||||
<PARA>
|
||||
This would work if table "table" has fields "control" and "name"
|
||||
This would work if table <classname>table</> has fields <structfield>control</> and <structfield>name</>
|
||||
(and, perhaps, other fields):
|
||||
<ProgramListing>
|
||||
pg_select $pgconn "SELECT * from table" array {
|
||||
|
@ -1136,7 +1136,7 @@ The oid of the large object created.
|
|||
</TITLE>
|
||||
<PARA>
|
||||
mode can be any OR'ing together of INV_READ and INV_WRITE.
|
||||
The OR delimiter character is "|".
|
||||
The OR delimiter character is <literal>|</literal>.
|
||||
<ProgramListing>
|
||||
[pg_lo_creat $conn "INV_READ|INV_WRITE"]
|
||||
</ProgramListing>
|
||||
|
@ -1237,7 +1237,7 @@ A file descriptor for use in later pg_lo* routines.
|
|||
<TITLE>Usage
|
||||
</TITLE>
|
||||
<PARA>
|
||||
Mode can be either "r", "w", or "rw".
|
||||
Mode can be either <literal>r</>, <literal>w</>, or <literal>rw</>.
|
||||
</PARA>
|
||||
</REFSECT1>
|
||||
</REFENTRY>
|
||||
|
@ -1583,7 +1583,7 @@ File descriptor for the large object from pg_lo_open.
|
|||
<REPLACEABLE CLASS="PARAMETER">whence</REPLACEABLE>
|
||||
</TERM>
|
||||
<LISTITEM>
|
||||
<PARA> whence can be "SEEK_CUR", "SEEK_END", or "SEEK_SET" </PARA>
|
||||
<PARA> whence can be <literal>SEEK_CUR</>, <literal>SEEK_END</>, or <literal>SEEK_SET</> </PARA>
|
||||
</LISTITEM>
|
||||
</VARLISTENTRY>
|
||||
</VARIABLELIST>
|
||||
|
@ -1614,7 +1614,7 @@ to <REPLACEABLE CLASS="PARAMETER">offset</REPLACEABLE> bytes from the beginning
|
|||
</TITLE>
|
||||
<PARA>
|
||||
<REPLACEABLE CLASS="PARAMETER">whence</REPLACEABLE>
|
||||
can be "SEEK_CUR", "SEEK_END", or "SEEK_SET".
|
||||
can be <literal>SEEK_CUR</literal>, <literal>SEEK_END</>, or <literal>SEEK_SET</literal>.
|
||||
</PARA>
|
||||
</REFSECT1>
|
||||
</REFENTRY>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.31 2001/09/10 21:58:46 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.32 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpqplusplus">
|
||||
|
@ -779,7 +779,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.31 2001/09/10 21:58:
|
|||
<function>PgDatabase::PutLine</function>
|
||||
or when the last string has been received from the backend using
|
||||
<function>PgDatabase::GetLine</function>.
|
||||
It must be issued or the backend may get "out of sync" with
|
||||
It must be issued or the backend may get <quote>out of sync</quote> with
|
||||
the frontend. Upon return from this function, the backend is ready to
|
||||
receive the next query.
|
||||
</para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.71 2001/09/10 21:58:46 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.72 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
|
@ -189,16 +189,16 @@ PGconn *PQconnectdb(const char *conninfo)
|
|||
<term><literal>requiressl</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Set to '1' to require SSL connection to the backend. <application>Libpq</>
|
||||
Set to 1 to require SSL connection to the backend. <application>Libpq</>
|
||||
will then refuse to connect if the server does not support
|
||||
SSL. Set to '0' (default) to negotiate with server.
|
||||
SSL. Set to 0 (default) to negotiate with server.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
If any parameter is unspecified, then the corresponding
|
||||
environment variable (see "Environment Variables" section)
|
||||
environment variable (see <xref linkend="libpq-envars">)
|
||||
is checked. If the environment variable is not set either,
|
||||
then hardwired defaults are used.
|
||||
The return value is a pointer to an abstract struct
|
||||
|
@ -1158,7 +1158,7 @@ Oid PQoidValue(const PGresult *res);
|
|||
<function>PQoidStatus</function>
|
||||
Returns a string with the object id of the tuple inserted, if the
|
||||
<acronym>SQL</acronym> command was an INSERT.
|
||||
(The string will be "0" if the INSERT did not insert exactly one
|
||||
(The string will be <literal>0</> if the INSERT did not insert exactly one
|
||||
row, or if the target table does not have OIDs.) If the command
|
||||
was not an INSERT, returns an empty string.
|
||||
<synopsis>
|
||||
|
@ -1328,7 +1328,7 @@ functions:
|
|||
<synopsis>
|
||||
int PQconsumeInput(PGconn *conn);
|
||||
</synopsis>
|
||||
<function>PQconsumeInput</function> normally returns 1 indicating "no error",
|
||||
<function>PQconsumeInput</function> normally returns 1 indicating <quote>no error</quote>,
|
||||
but returns 0 if there was some kind of trouble (in which case
|
||||
<function>PQerrorMessage</function> is set). Note that the result does not say
|
||||
whether any input data was actually collected. After calling
|
||||
|
@ -1416,8 +1416,7 @@ When the main loop detects input ready, it should call
|
|||
<function>PQconsumeInput</function> to read the input. It can then call
|
||||
<function>PQisBusy</function>, followed by <function>PQgetResult</function>
|
||||
if <function>PQisBusy</function> returns false (0). It can also call
|
||||
<function>PQnotifies</function> to detect NOTIFY messages (see "Asynchronous
|
||||
Notification", below).
|
||||
<function>PQnotifies</function> to detect NOTIFY messages (see <xref linkend="libpq-notify">).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1653,12 +1652,12 @@ terminating newline has not yet been read.
|
|||
</para>
|
||||
<para>
|
||||
Notice that the application must check to see if a
|
||||
new line consists of the two characters "\.",
|
||||
new line consists of the two characters <literal>\.</literal>,
|
||||
which indicates that the backend server has finished sending
|
||||
the results of the copy command.
|
||||
If the application might
|
||||
receive lines that are more than length-1 characters long,
|
||||
care is needed to be sure one recognizes the "\." line correctly
|
||||
care is needed to be sure one recognizes the <literal>\.</literal> line correctly
|
||||
(and does not, for example, mistake the end of a long data line
|
||||
for a terminator line).
|
||||
The code in
|
||||
|
@ -1703,7 +1702,7 @@ The data returned will not extend beyond a newline character. If possible
|
|||
a whole line will be returned at one time. But if the buffer offered by
|
||||
the caller is too small to hold a line sent by the backend, then a partial
|
||||
data line will be returned. This can be detected by testing whether the
|
||||
last returned byte is "<literal>\n</literal>" or not.
|
||||
last returned byte is <literal>\n</literal> or not.
|
||||
The returned string is not null-terminated. (If you want to add a
|
||||
terminating null, be sure to pass a <parameter>bufsize</parameter> one smaller than the room
|
||||
actually available.)
|
||||
|
@ -1720,7 +1719,7 @@ int PQputline(PGconn *conn,
|
|||
const char *string);
|
||||
</synopsis>
|
||||
Note the application must explicitly send the two
|
||||
characters "<literal>\.</literal>" on a final line to indicate to
|
||||
characters <literal>\.</literal> on a final line to indicate to
|
||||
the backend that it has finished sending its data.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -1750,7 +1749,7 @@ specified directly.
|
|||
sent to the backend using <function>PQputline</function> or when the
|
||||
last string has been received from the backend
|
||||
using <function>PGgetline</function>. It must be issued or the backend
|
||||
may get "out of sync" with the frontend. Upon
|
||||
may get <quote>out of sync</quote> with the frontend. Upon
|
||||
return from this function, the backend is ready to
|
||||
receive the next query.
|
||||
The return value is 0 on successful completion,
|
||||
|
@ -1853,7 +1852,7 @@ PQsetNoticeProcessor(PGconn *conn,
|
|||
</para>
|
||||
|
||||
<para>
|
||||
By default, <application>libpq</application> prints "notice"
|
||||
By default, <application>libpq</application> prints notice
|
||||
messages from the backend on <filename>stderr</filename>,
|
||||
as well as a few error messages that it generates by itself.
|
||||
This behavior can be overridden by supplying a callback function that
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.19 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.20 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="largeObjects">
|
||||
|
@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.19 2001/09/10 21:58:47 petere
|
|||
|
||||
<para>
|
||||
The Inversion large object implementation breaks large
|
||||
objects up into "chunks" and stores the chunks in
|
||||
objects up into <quote>chunks</quote> and stores the chunks in
|
||||
tuples in the database. A B-tree index guarantees fast
|
||||
searches for the correct chunk number when doing random
|
||||
access reads and writes.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.14 2001/09/09 23:52:12 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.15 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="managing-databases">
|
||||
|
@ -237,7 +237,7 @@ Type: \copyright for distribution terms
|
|||
workspace maintained by the terminal monitor.
|
||||
The <application>psql</application> program responds to escape
|
||||
codes that begin
|
||||
with the backslash character, "\". For example, you
|
||||
with the backslash character, <literal>\</literal>. For example, you
|
||||
can get help on the syntax of various
|
||||
<productname>Postgres</productname> <acronym>SQL</acronym> commands by typing:
|
||||
|
||||
|
@ -278,7 +278,7 @@ Type: \copyright for distribution terms
|
|||
Single-line comments are denoted by two dashes
|
||||
("<literal>--</literal>"). Everything after the dashes up to the end of the
|
||||
line is ignored. Multiple-line comments, and comments within a line,
|
||||
are denoted by "<literal>/* ... */</literal>", a convention borrowed
|
||||
are denoted by <literal>/* ... */</literal>, a convention borrowed
|
||||
from <productname>Ingres</productname>.
|
||||
</para>
|
||||
</sect1>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.15 2001/09/10 05:20:23 ishii Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.16 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="manage">
|
||||
|
@ -225,7 +225,7 @@ This prompt indicates that <command>psql</command> is listening
|
|||
to you and that you can type <Acronym>SQL</Acronym> queries into a
|
||||
workspace maintained by the terminal monitor.
|
||||
The <Application>psql</Application> program responds to escape codes that begin
|
||||
with the backslash character, "<literal>\</literal>". For example, you
|
||||
with the backslash character, <literal>\</literal>. For example, you
|
||||
can get help on the syntax of various
|
||||
<ProductName>PostgreSQL</ProductName> <Acronym>SQL</Acronym> commands by typing:
|
||||
<ProgramListing>
|
||||
|
@ -240,7 +240,7 @@ mydb=> \g
|
|||
</ProgramListing>
|
||||
|
||||
This tells the server to process the query. If you
|
||||
terminate your query with a semicolon, the "<literal>\g</literal>" is not
|
||||
terminate your query with a semicolon, the <literal>\g</literal> is not
|
||||
necessary.
|
||||
<Application>psql</Application> will automatically process semicolon terminated queries.
|
||||
To read queries from a file, say <filename>myFile</filename>, instead of
|
||||
|
@ -259,9 +259,9 @@ mydb=> \q
|
|||
prompt.)
|
||||
White space (i.e., spaces, tabs and newlines) may be
|
||||
used freely in <Acronym>SQL</Acronym> queries. Single-line comments are denoted by
|
||||
"<literal>--</literal>". Everything after the dashes up to the end of the
|
||||
<literal>--</literal>. Everything after the dashes up to the end of the
|
||||
line is ignored. Multiple-line comments, and comments within a line,
|
||||
are denoted by "<literal>/* ... */</literal>".
|
||||
are denoted by <literal>/* ... */</literal>.
|
||||
</Para>
|
||||
|
||||
</Sect1>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.17 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.18 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="mvcc">
|
||||
|
@ -331,7 +331,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||
the row still exists at the time it is returned (i.e. sometime after the
|
||||
current transaction began); the row might have been modified or deleted
|
||||
by an already-committed transaction that committed after this one started.
|
||||
Even if the row is still valid "now", it could be changed or deleted
|
||||
Even if the row is still valid <quote>now</quote>, it could be changed or deleted
|
||||
before the current transaction does a commit or rollback.
|
||||
</para>
|
||||
|
||||
|
@ -339,7 +339,7 @@ ERROR: Can't serialize access due to concurrent update
|
|||
Another way to think about it is that each
|
||||
transaction sees a snapshot of the database contents, and concurrently
|
||||
executing transactions may very well see different snapshots. So the
|
||||
whole concept of "now" is somewhat suspect anyway. This is not normally
|
||||
whole concept of <quote>now</quote> is somewhat suspect anyway. This is not normally
|
||||
a big problem if the client applications are isolated from each other,
|
||||
but if the clients can communicate via channels outside the database
|
||||
then serious confusion may ensue.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.15 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.16 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="notation">
|
||||
|
@ -29,10 +29,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.15 2001/09/09 17:21:59 pe
|
|||
|
||||
<para>
|
||||
In a command synopsis, brackets
|
||||
("<literal>[</literal>" and "<literal>]</literal>") indicate an optional phrase or keyword.
|
||||
(<literal>[</literal> and <literal>]</literal>) indicate an optional phrase or keyword.
|
||||
Anything in braces
|
||||
("<literal>{</literal>" and "<literal>}</literal>") and containing vertical bars
|
||||
("<literal>|</literal>")
|
||||
(<literal>{</literal> and <literal>}</literal>) and containing vertical bars
|
||||
(<literal>|</literal>)
|
||||
indicates that you must choose one.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.23 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.24 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="odbc">
|
||||
|
@ -451,7 +451,7 @@ TextAsLongVarchar=0
|
|||
</step>
|
||||
<step performance="required">
|
||||
<para>
|
||||
The 'Ready' message will appear in the lower left corner of the data
|
||||
The <literal>Ready</literal> message will appear in the lower left corner of the data
|
||||
window. This indicates that you can now enter queries.
|
||||
</para>
|
||||
</step>
|
||||
|
@ -663,13 +663,13 @@ can't load library 'libodbc.so'\n", 61) = -1 EIO (I/O error)
|
|||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Search for 'null_clause = "NULL"
|
||||
Search for <literal>null_clause = "NULL"</literal>.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Change this to null_clause = ""
|
||||
Change this to <literal>null_clause = ""</literal>.
|
||||
</para>
|
||||
</step>
|
||||
|
||||
|
@ -713,7 +713,7 @@ can't load library 'libodbc.so'\n", 61) = -1 EIO (I/O error)
|
|||
|
||||
<step performance="required">
|
||||
<para>
|
||||
Enter the value "<literal>sqldemo</literal>", then click <command>OK</command>.
|
||||
Enter the value <literal>sqldemo</literal>, then click <command>OK</command>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.8 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.9 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="performance-tips">
|
||||
|
@ -192,13 +192,13 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
|
|||
<para>
|
||||
In this nested-loop join, the outer scan is the same index scan we had
|
||||
in the example before last, and so its cost and row count are the same
|
||||
because we are applying the "unique1 < 50" WHERE clause at that node.
|
||||
The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't
|
||||
because we are applying the <literal>unique1 < 50</literal> WHERE clause at that node.
|
||||
The <literal>t1.unique2 = t2.unique2</literal> clause is not relevant yet, so it doesn't
|
||||
affect row count of the outer scan. For the inner scan, the unique2 value of the
|
||||
current
|
||||
outer-scan tuple is plugged into the inner index scan
|
||||
to produce an index qualification like
|
||||
"t2.unique2 = <replaceable>constant</replaceable>". So we get the
|
||||
<literal>t2.unique2 = <replaceable>constant</replaceable></literal>. So we get the
|
||||
same inner-scan plan and costs that we'd get from, say, <literal>explain select
|
||||
* from tenk2 where unique2 = 42</literal>. The costs of the loop node are then set
|
||||
on the basis of the cost of the outer scan, plus one repetition of the
|
||||
|
@ -211,7 +211,7 @@ Nested Loop (cost=0.00..269.11 rows=47 width=296)
|
|||
of the two scans' row counts, but that's not true in general, because
|
||||
in general you can have WHERE clauses that mention both relations and
|
||||
so can only be applied at the join point, not to either input scan.
|
||||
For example, if we added "WHERE ... AND t1.hundred < t2.hundred",
|
||||
For example, if we added <literal>WHERE ... AND t1.hundred < t2.hundred</literal>,
|
||||
that would decrease the output row count of the join node, but not change
|
||||
either input scan.
|
||||
</para>
|
||||
|
@ -240,7 +240,7 @@ Hash Join (cost=173.44..557.03 rows=47 width=296)
|
|||
This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
|
||||
using ye same olde index scan, stash them into an in-memory hash table,
|
||||
and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
|
||||
for possible matches of "t1.unique2 = t2.unique2" at each <classname>tenk2</classname> tuple.
|
||||
for possible matches of <literal>t1.unique2 = t2.unique2</literal> at each <classname>tenk2</classname> tuple.
|
||||
The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
|
||||
cost for the hash join, since we won't get any tuples out until we can
|
||||
start reading <classname>tenk2</classname>. The total time estimate for the join also
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.3 2001/09/12 03:58:15 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.4 2001/09/13 15:55:23 petere Exp $ -->
|
||||
|
||||
<chapter id="plpython">
|
||||
<title>PL/Python - Python Procedural Language</title>
|
||||
|
@ -69,23 +69,23 @@ def __plpython_procedure_myfunc_23456():
|
|||
dictionary, as mentioned above.
|
||||
</para>
|
||||
|
||||
</para>
|
||||
<para>
|
||||
When a function is used in a trigger, the dictionary TD contains
|
||||
transaction related values. The trigger tuples are in TD["new"]
|
||||
and/or TD["old"] depending on the trigger event. TD["event"]
|
||||
contains the event as a string ("INSERT", "UPDATE", "DELETE", or
|
||||
"UNKNOWN"). TD["when"] contains one of ("BEFORE", "AFTER", or
|
||||
"UNKNOWN"). TD["level"] contains one of ("ROW", "STATEMENT", or
|
||||
"UNKNOWN"). TD["name"] contains the trigger name, and TD["relid"]
|
||||
transaction related values. The trigger tuples are in <literal>TD["new"]</>
|
||||
and/or <literal>TD["old"]</> depending on the trigger event. <literal>TD["event"]</>
|
||||
contains the event as a string (<literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>, or
|
||||
<literal>UNKNOWN</>). TD["when"] contains one of (<literal>BEFORE</>, <literal>AFTER</>, or
|
||||
<literal>UNKNOWN</>). <literal>TD["level"]</> contains one of <literal>ROW</>, <literal>STATEMENT</>, or
|
||||
<literal>UNKNOWN</>. <literal>TD["name"]</> contains the trigger name, and <literal>TD["relid"]</>
|
||||
contains the relation id of the table on which the trigger occurred.
|
||||
If the trigger was called with arguments they are available
|
||||
in TD["args"][0] to TD["args"][(n -1)]
|
||||
in <literal>TD["args"][0]</> to <literal>TD["args"][(n -1)]</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the trigger 'when' is "BEFORE", you may Return 'None' or "OK"
|
||||
from the python function to indicate the tuple is unmodified,
|
||||
"SKIP" to abort the event, or "MODIFIED" to indicate you've
|
||||
If the trigger <quote>when</quote> is <literal>BEFORE</>, you may return <literal>None</literal> or <literal>"OK"</literal>
|
||||
from the Python function to indicate the tuple is unmodified,
|
||||
<literal>"SKIP"</> to abort the event, or <literal>"MODIFIED"</> to indicate you've
|
||||
modified the tuple.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.38 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.39 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
|
@ -739,7 +739,7 @@ EXECUTE <replaceable class="command">query-string</replaceable>
|
|||
<para>
|
||||
When working with dynamic queries you will have to face
|
||||
escaping of single quotes in <application>PL/pgSQL</>. Please refer to the
|
||||
table available at the "Porting from Oracle PL/SQL" chapter
|
||||
table available at the <xref linkend="plpgsql-porting">
|
||||
for a detailed explanation that will save you some effort.
|
||||
</para>
|
||||
|
||||
|
@ -961,7 +961,7 @@ END IF;
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
When you use the "ELSE IF" statement, you are actually
|
||||
When you use the <literal>ELSE IF</> statement, you are actually
|
||||
nesting an IF statement inside the ELSE
|
||||
statement. Thus you need one END IF statement for each
|
||||
nested IF and one for the parent IF-ELSE.
|
||||
|
@ -1221,7 +1221,7 @@ SELECT INTO <replaceable>target</replaceable> <replaceable>expressions</replace
|
|||
|
||||
<para>
|
||||
Once a record or row has been assigned to a RECORD variable,
|
||||
you can use the "." (dot) notation to access fields in that
|
||||
you can use the <literal>.</> (dot) notation to access fields in that
|
||||
record:
|
||||
<programlisting>
|
||||
DECLARE
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.13 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.14 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="pltcl">
|
||||
|
@ -365,31 +365,31 @@ CREATE TRIGGER trig_mytab_modcount BEFORE INSERT OR UPDATE ON mytab
|
|||
<function>spi_execp</function>).
|
||||
Think about a query string like
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
"SELECT '$val' AS ret"
|
||||
</programlisting>
|
||||
</programlisting>
|
||||
|
||||
where the Tcl variable val actually contains "doesn't". This would result
|
||||
where the Tcl variable val actually contains <literal>doesn't</literal>. This would result
|
||||
in the final query string
|
||||
|
||||
<programlisting>
|
||||
"SELECT 'doesn't' AS ret"
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
SELECT 'doesn't' AS ret
|
||||
</programlisting>
|
||||
|
||||
which would cause a parse error during
|
||||
<function>spi_exec</function> or
|
||||
<function>spi_prepare</function>.
|
||||
It should contain
|
||||
|
||||
<programlisting>
|
||||
"SELECT 'doesn''t' AS ret"
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
SELECT 'doesn''t' AS ret
|
||||
</programlisting>
|
||||
|
||||
and has to be written as
|
||||
|
||||
<programlisting>
|
||||
"SELECT '[ quote $val ]' AS ret"
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
SELECT '[ quote $val ]' AS ret
|
||||
</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.9 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="bug-reporting">
|
||||
|
@ -102,7 +102,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 pet
|
|||
<para>
|
||||
The most important thing to remember about bug reporting is to state all
|
||||
the facts and only facts. Do not speculate what you think went wrong, what
|
||||
"it seemed to do", or which part of the program has a fault.
|
||||
<quote>it seemed to do</quote>, or which part of the program has a fault.
|
||||
If you are not familiar with the implementation you would probably guess
|
||||
wrong and not help us a bit. And even if you are, educated explanations are
|
||||
a great supplement to but no substitute for facts. If we are going to fix
|
||||
|
@ -144,7 +144,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 pet
|
|||
please try to isolate the offending queries. We will probably not set up a
|
||||
web server to reproduce your problem. In any case remember to provide
|
||||
the exact input files, do not guess that the problem happens for
|
||||
"large files" or "mid-size databases", etc. since this
|
||||
<quote>large files</quote> or <quote>mid-size databases</quote>, etc. since this
|
||||
information is too inexact to be of use.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -172,12 +172,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 pet
|
|||
<listitem>
|
||||
<para>
|
||||
The output you expected is very important to state. If you just write
|
||||
"This command gives me that output." or "This is not
|
||||
what I expected.", we might run it ourselves, scan the output, and
|
||||
<quote>This command gives me that output.</quote> or <quote>This is not
|
||||
what I expected.</quote>, we might run it ourselves, scan the output, and
|
||||
think it looks OK and is exactly what we expected. We should not have to
|
||||
spend the time to decode the exact semantics behind your commands.
|
||||
Especially refrain from merely saying that "This is not what SQL says/Oracle
|
||||
does." Digging out the correct behavior from <acronym>SQL</acronym>
|
||||
Especially refrain from merely saying that <quote>This is not what SQL says/Oracle
|
||||
does.</quote> Digging out the correct behavior from <acronym>SQL</acronym>
|
||||
is not a fun undertaking, nor do we all know how all the other relational
|
||||
databases out there behave. (If your problem is a program crash you can
|
||||
obviously omit this item.)
|
||||
|
@ -231,7 +231,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 pet
|
|||
Platform information. This includes the kernel name and version, C library,
|
||||
processor, memory information. In most cases it is sufficient to report
|
||||
the vendor and version, but do not assume everyone knows what exactly
|
||||
"Debian" contains or that everyone runs on Pentiums. If
|
||||
<quote>Debian</quote> contains or that everyone runs on Pentiums. If
|
||||
you have installation problems then information about compilers, make,
|
||||
etc. is also necessary.
|
||||
</para>
|
||||
|
@ -254,12 +254,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 pet
|
|||
|
||||
<para>
|
||||
When writing a bug report, please choose non-confusing terminology.
|
||||
The software package as such is called "PostgreSQL",
|
||||
sometimes "Postgres" for short. (Sometimes
|
||||
the abbreviation "Pgsql" is used but don't do that.) When you
|
||||
The software package as such is called <quote>PostgreSQL</quote>,
|
||||
sometimes <quote>Postgres</quote> for short. (Sometimes
|
||||
the abbreviation <quote>Pgsql</quote> is used but don't do that.) When you
|
||||
are specifically talking about the backend server, mention that, do not
|
||||
just say "Postgres crashes". The interactive frontend is called
|
||||
"psql" and is for all intends and purposes completely separate
|
||||
just say <quote>Postgres crashes</quote>. The interactive frontend is called
|
||||
<quote>psql</quote> and is for all intends and purposes completely separate
|
||||
from the backend.
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.19 2001/08/15 18:42:14 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/protocol.sgml,v 1.20 2001/09/13 15:55:23 petere Exp $ -->
|
||||
|
||||
<chapter id="protocol">
|
||||
<title>Frontend/Backend Protocol</title>
|
||||
|
@ -628,8 +628,8 @@ This section describes the base data types used in messages.
|
|||
</Term>
|
||||
<ListItem>
|
||||
<Para>
|
||||
A character array of exactly <Replaceable>n</Replaceable> bytes interpreted as a '\0'
|
||||
terminated string. The '\0' is omitted if there is
|
||||
A character array of exactly <Replaceable>n</Replaceable> bytes interpreted as a
|
||||
null-terminated string. The zero-byte is omitted if there is
|
||||
insufficient room. If <Replaceable>s</Replaceable> is specified it is the literal value.
|
||||
Eg. LimString32, LimString64("user").
|
||||
</Para>
|
||||
|
@ -641,7 +641,7 @@ This section describes the base data types used in messages.
|
|||
</Term>
|
||||
<ListItem>
|
||||
<Para>
|
||||
A conventional C '\0' terminated string with no length
|
||||
A conventional C null-terminated string with no length
|
||||
limitation.
|
||||
If <Replaceable>s</Replaceable> is specified it is the literal value.
|
||||
Eg. String, String("user").
|
||||
|
@ -739,7 +739,7 @@ AsciiRow (B)
|
|||
Specifies the value of the field itself in <Acronym>ASCII</Acronym>
|
||||
characters. <Replaceable>n</Replaceable> is the above
|
||||
size minus 4.
|
||||
There is no trailing '\0' in the field data; the front
|
||||
There is no trailing zero-byte in the field data; the front
|
||||
end must add one if it wants one.
|
||||
</Para>
|
||||
</ListItem>
|
||||
|
@ -1073,7 +1073,7 @@ CancelRequest (F)
|
|||
<ListItem>
|
||||
<Para>
|
||||
The cancel request code. The value is chosen to contain
|
||||
"1234" in the most significant 16 bits, and "5678" in the
|
||||
<literal>1234</> in the most significant 16 bits, and <literal>5678</> in the
|
||||
least 16 significant bits. (To avoid confusion, this code
|
||||
must not be the same as any protocol version number.)
|
||||
</Para>
|
||||
|
@ -1226,7 +1226,7 @@ CursorResponse (B)
|
|||
</Term>
|
||||
<ListItem>
|
||||
<Para>
|
||||
The name of the cursor. This will be "blank" if the cursor is
|
||||
The name of the cursor. This will be <quote>blank</> if the cursor is
|
||||
implicit.
|
||||
</Para>
|
||||
</ListItem>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/Attic/pygresql.sgml,v 1.2 2001/09/10 04:15:41 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/Attic/pygresql.sgml,v 1.3 2001/09/13 15:55:23 petere Exp $ -->
|
||||
|
||||
<chapter id="pygresql">
|
||||
<title><application>PyGreSQL</application> - <application>Python</application> Interface</title>
|
||||
|
@ -236,10 +236,10 @@ cc -fpic -shared -o _pg.so -I[pyInc] -I[pgInc] -L[pgLib] -lpq pgmodule.c
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
Find the directory where your '<filename>Setup</filename>'
|
||||
Find the directory where your <filename>Setup</filename>
|
||||
file lives (usually <filename>??/Modules</filename>) in
|
||||
the <productname>Python</productname> source hierarchy and
|
||||
copy or symlink the '<filename>pgmodule.c</filename>' file there.
|
||||
copy or symlink the <filename>pgmodule.c</filename> file there.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -305,9 +305,9 @@ _pg pgmodule.c -I[pgInc] -L[pgLib] -lpq # -lcrypt # needed on some systems
|
|||
<listitem>
|
||||
<para>
|
||||
If you want a shared module, make sure that the
|
||||
"<literal>*shared*</literal>" keyword is uncommented and
|
||||
<literal>*shared*</literal> keyword is uncommented and
|
||||
add the above line below it. You used to need to install
|
||||
your shared modules with "make sharedinstall" but this no
|
||||
your shared modules with <literal>make sharedinstall</> but this no
|
||||
longer seems to be true.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.23 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/copy.sgml,v 1.24 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -380,7 +380,7 @@ ERROR: <replaceable>reason</replaceable>
|
|||
<term>Signature</term>
|
||||
<listitem>
|
||||
<para>
|
||||
12-byte sequence "PGBCOPY\n\377\r\n\0" --- note that the null
|
||||
12-byte sequence <literal>PGBCOPY\n\377\r\n\0</> --- note that the null
|
||||
is a required part of the signature. (The signature is designed to allow
|
||||
easy identification of files that have been munged by a non-8-bit-clean
|
||||
transfer. This signature will be changed by newline-translation
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.14 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.15 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -206,7 +206,7 @@ CREATE
|
|||
</para>
|
||||
|
||||
<para>
|
||||
If the state transition function is declared "strict" in pg_proc,
|
||||
If the state transition function is declared <quote>strict</quote>,
|
||||
then it cannot be called with NULL inputs. With such a transition
|
||||
function, aggregate execution behaves as follows. NULL input values
|
||||
are ignored (the function is not called and the previous state value
|
||||
|
@ -230,7 +230,7 @@ CREATE
|
|||
</para>
|
||||
|
||||
<para>
|
||||
If the final function is declared "strict", then it will not
|
||||
If the final function is declared <quote>strict</quote>, then it will not
|
||||
be called when the ending state value is NULL; instead a NULL result
|
||||
will be output automatically. (Of course this is just the normal
|
||||
behavior of strict functions.) In any case the final function has
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.19 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_database.sgml,v 1.20 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -186,11 +186,11 @@ CREATE DATABASE <replaceable class="PARAMETER">name</replaceable>
|
|||
as an environment variable name, which must be known to the
|
||||
server process. This way the database administrator can
|
||||
exercise control over locations in which databases can be created.
|
||||
(A customary choice is, e.g., '<envar>PGDATA2</envar>'.)
|
||||
(A customary choice is, e.g., <envar>PGDATA2</envar>.)
|
||||
If the server is compiled with <literal>ALLOW_ABSOLUTE_DBPATHS</literal>
|
||||
(not so by default), absolute path names, as identified by
|
||||
a leading slash
|
||||
(e.g., '<filename>/usr/local/pgsql/data</filename>'),
|
||||
(e.g., <filename>/usr/local/pgsql/data</filename>),
|
||||
are allowed as well.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.20 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.21 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -185,19 +185,20 @@ CREATE
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
"$" cannot be defined as a single-character operator,
|
||||
<literal>$</literal> cannot be defined as a single-character operator,
|
||||
although it can be part of a multi-character operator name.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
"--" and "/*" cannot appear anywhere in an operator name,
|
||||
<literal>--</literal> and <literal>/*</literal> cannot appear anywhere in an operator name,
|
||||
since they will be taken as the start of a comment.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
A multi-character operator name cannot end in "+" or "-",
|
||||
A multi-character operator name cannot end in <literal>+</literal> or
|
||||
<literal>-</literal>,
|
||||
unless the name also contains at least one of these characters:
|
||||
<literallayout>
|
||||
~ ! @ # % ^ & | ` ? $
|
||||
|
@ -214,7 +215,7 @@ CREATE
|
|||
<para>
|
||||
When working with non-SQL-standard operator names, you will usually
|
||||
need to separate adjacent operators with spaces to avoid ambiguity.
|
||||
For example, if you have defined a left-unary operator named "@",
|
||||
For example, if you have defined a left-unary operator named <literal>@</literal>,
|
||||
you cannot write <literal>X*@Y</literal>; you must write
|
||||
<literal>X* @Y</literal> to ensure that
|
||||
<productname>Postgres</productname> reads it as two operator names
|
||||
|
@ -223,7 +224,7 @@ CREATE
|
|||
</note>
|
||||
</para>
|
||||
<para>
|
||||
The operator "!=" is mapped to "<>" on input, so these two names
|
||||
The operator <literal>!=</literal> is mapped to <literal><></literal> on input, so these two names
|
||||
are always equivalent.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.19 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_sequence.sgml,v 1.20 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -270,7 +270,7 @@ SELECT last_value FROM <replaceable>seqname</replaceable>;
|
|||
that obtain numbers from the same sequence, a nextval operation
|
||||
is never rolled back; that is, once a value has been fetched it is
|
||||
considered used, even if the transaction that did the nextval later
|
||||
aborts. This means that aborted transactions may leave unused "holes"
|
||||
aborts. This means that aborted transactions may leave unused <quote>holes</quote>
|
||||
in the sequence of assigned values. setval operations are never
|
||||
rolled back, either.
|
||||
</para>
|
||||
|
@ -315,7 +315,7 @@ SELECT last_value FROM <replaceable>seqname</replaceable>;
|
|||
<para>
|
||||
Each backend uses its own cache to store preallocated numbers.
|
||||
Numbers that are cached but not used in the current session will be
|
||||
lost, resulting in "holes" in the sequence.
|
||||
lost, resulting in <quote>holes</quote> in the sequence.
|
||||
</para>
|
||||
</refsect2>
|
||||
</refsect1>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.45 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_table.sgml,v 1.46 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -236,7 +236,7 @@ ERROR: Relation '<replaceable class="parameter">table</replaceable>' already ex
|
|||
|
||||
<para>
|
||||
<command>CREATE TABLE</command> will enter a new, initially empty table
|
||||
into the current database. The table will be "owned" by the user issuing the
|
||||
into the current database. The table will be owned by the user issuing the
|
||||
command.
|
||||
</para>
|
||||
|
||||
|
@ -1253,8 +1253,8 @@ ERROR: <replaceable class="parameter">name</replaceable> referential integrity
|
|||
|
||||
<para>
|
||||
A table constraint is an integrity constraint defined on one or
|
||||
more columns of a table. The four variations of "Table
|
||||
Constraint" are:
|
||||
more columns of a table. The four variations of <quote>Table
|
||||
Constraint</quote> are:
|
||||
<simplelist columns="1">
|
||||
<member>UNIQUE</member>
|
||||
<member>CHECK</member>
|
||||
|
@ -1898,7 +1898,7 @@ CREATE GLOBAL TEMPORARY TABLE <replaceable class="parameter">table</replaceable>
|
|||
NULL clause
|
||||
</title>
|
||||
<para>
|
||||
The NULL "constraint" (actually a non-constraint) is a
|
||||
The NULL <quote>constraint</quote> (actually a non-constraint) is a
|
||||
<productname>Postgres</productname> extension to SQL92 that is
|
||||
included for symmetry with the NOT NULL clause (and for compatibility
|
||||
with some other RDBMSes). Since it is the
|
||||
|
@ -1927,7 +1927,7 @@ CREATE GLOBAL TEMPORARY TABLE <replaceable class="parameter">table</replaceable>
|
|||
<!--
|
||||
I can't figure out why DEFAULT clause is different from what we already have.
|
||||
Perhaps because CURRENT_USER and CURRENT_DATE have specific types (currently
|
||||
the "name" type), if you aren't careful then the types won't match up with
|
||||
the <type>name</type> type), if you aren't careful then the types won't match up with
|
||||
the column. Not our problem...
|
||||
- Thomas 1998-08-16
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.15 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_trigger.sgml,v 1.16 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -126,7 +126,7 @@ CREATE
|
|||
being inserted (for <command>INSERT</command> and
|
||||
<command>UPDATE</command> operations only). If
|
||||
the trigger fires after the event, all changes, including the
|
||||
last insertion, update, or deletion, are "visible" to the trigger.
|
||||
last insertion, update, or deletion, are <quote>visible</quote> to the trigger.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.21 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_type.sgml,v 1.22 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -153,9 +153,9 @@ CREATE TYPE <replaceable class="parameter">typename</replaceable> ( INPUT = <rep
|
|||
<listitem>
|
||||
<para>
|
||||
Storage alignment requirement of the data type. If specified, must
|
||||
be '<literal>char</literal>', '<literal>int2</literal>',
|
||||
'<literal>int4</literal>', or '<literal>double</literal>';
|
||||
the default is '<literal>int4</literal>'.
|
||||
be <literal>char</literal>, <literal>int2</literal>,
|
||||
<literal>int4</literal>, or <literal>double</literal>;
|
||||
the default is <literal>int4</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -165,9 +165,9 @@ CREATE TYPE <replaceable class="parameter">typename</replaceable> ( INPUT = <rep
|
|||
<listitem>
|
||||
<para>
|
||||
Storage technique for the data type. If specified, must
|
||||
be '<literal>plain</literal>', '<literal>external</literal>',
|
||||
'<literal>extended</literal>', or '<literal>main</literal>';
|
||||
the default is '<literal>plain</literal>'.
|
||||
be <literal>plain</literal>, <literal>external</literal>,
|
||||
<literal>extended</literal>, or <literal>main</literal>;
|
||||
the default is <literal>plain</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -228,7 +228,7 @@ CREATE
|
|||
<replaceable class="parameter">output_function</replaceable>
|
||||
performs the reverse transformation. Both
|
||||
the input and output functions must be declared to take
|
||||
one or two arguments of type "<literal>opaque</literal>".
|
||||
one or two arguments of type <type>opaque</type>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -237,7 +237,7 @@ CREATE
|
|||
positive integer, or variable length,
|
||||
in which case Postgres assumes that the new type has the
|
||||
same format
|
||||
as the Postgres-supplied data type, "<literal>text</literal>".
|
||||
as the Postgres-supplied data type, <type>text</type>.
|
||||
To indicate that a type is variable length, set
|
||||
<replaceable class="parameter">internallength</replaceable>
|
||||
to <option>VARIABLE</option>.
|
||||
|
@ -264,7 +264,7 @@ CREATE
|
|||
|
||||
<para>
|
||||
A default value is optionally available in case a user
|
||||
wants some specific bit pattern to mean "data not present."
|
||||
wants some specific bit pattern to mean <quote>data not present</quote>.
|
||||
Specify the default with the <literal>DEFAULT</literal> keyword.
|
||||
<comment>How does the user specify that bit pattern and associate
|
||||
it with the fact that the data is not present></comment>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/declare.sgml,v 1.13 2001/09/03 12:57:49 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/declare.sgml,v 1.14 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -210,9 +210,9 @@ ERROR: DECLARE CURSOR may only be used in begin/end transaction blocks
|
|||
|
||||
<para>
|
||||
As an example, if a query returns a value of one from an integer column,
|
||||
you would get a string of '1' with a default cursor
|
||||
you would get a string of <literal>1</> with a default cursor
|
||||
whereas with a binary cursor you would get
|
||||
a 4-byte value equal to control-A ('^A').
|
||||
a 4-byte value equal to control-A (<literal>^A</literal>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -227,7 +227,7 @@ ERROR: DECLARE CURSOR may only be used in begin/end transaction blocks
|
|||
<emphasis><productname>Postgres</productname> does not resolve
|
||||
byte ordering or representation issues for binary cursors</emphasis>.
|
||||
Therefore, if your client machine and server machine use different
|
||||
representations (e.g., "big-endian" versus "little-endian"),
|
||||
representations (e.g., <quote>big-endian</quote> versus <quote>little-endian</quote>),
|
||||
you will probably not want your data returned in
|
||||
binary format.
|
||||
However, binary cursors may be a
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/fetch.sgml,v 1.15 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/fetch.sgml,v 1.16 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -188,7 +188,7 @@ ERROR: FETCH/RELATIVE at current position is not supported
|
|||
<listitem>
|
||||
<para>
|
||||
<acronym>SQL92</acronym> allows one to repetitively retrieve the cursor
|
||||
at its "current position" using the syntax
|
||||
at its <quote>current position</quote> using the syntax
|
||||
<synopsis>
|
||||
FETCH RELATIVE 0 FROM <replaceable class="PARAMETER">cursor</replaceable>.
|
||||
</synopsis>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/initlocation.sgml,v 1.12 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/initlocation.sgml,v 1.13 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -37,7 +37,7 @@ Postgres documentation
|
|||
which is referenced. See the examples at the end.
|
||||
</para>
|
||||
<para>
|
||||
In order to use this command you must be logged in (using 'su', for example)
|
||||
In order to use this command you must be logged in (using <command>su</command>, for example)
|
||||
as the database superuser.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/notify.sgml,v 1.14 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/notify.sgml,v 1.15 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -103,8 +103,8 @@ NOTIFY
|
|||
</para>
|
||||
<para>
|
||||
Commonly, the notify condition name is the same as the name of some table in
|
||||
the database, and the notify event essentially means "I changed this table,
|
||||
take a look at it to see what's new". But no such association is enforced by
|
||||
the database, and the notify event essentially means <quote>I changed this table,
|
||||
take a look at it to see what's new</quote>. But no such association is enforced by
|
||||
the <command>NOTIFY</command> and <command>LISTEN</command> commands. For
|
||||
example, a database designer could use several different condition names
|
||||
to signal different sorts of changes to a single table.
|
||||
|
@ -137,7 +137,7 @@ NOTIFY
|
|||
after the transaction is completed (either committed or aborted). Again, the
|
||||
reasoning is that if a notify were delivered within a transaction that was
|
||||
later aborted, one would want the notification to be undone somehow---but
|
||||
the backend cannot "take back" a notify once it has sent it to the frontend.
|
||||
the backend cannot <quote>take back</quote> a notify once it has sent it to the frontend.
|
||||
So notify events are only delivered between transactions. The upshot of this
|
||||
is that applications using <command>NOTIFY</command> for real-time signaling
|
||||
should try to keep their transactions short.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.15 2001/09/03 12:57:50 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.16 2001/09/13 15:55:24 petere Exp $ -->
|
||||
|
||||
<refentry id="APP-PGRESTORE">
|
||||
<docinfo>
|
||||
|
@ -295,7 +295,7 @@
|
|||
<listitem>
|
||||
<para>
|
||||
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 ';' at 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.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.59 2001/09/11 05:11:59 ishii Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.60 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -103,7 +103,7 @@ Postgres documentation
|
|||
<para>
|
||||
In normal operation, <application>psql</application> provides a prompt with
|
||||
the name of the database to which <application>psql</application> is currently
|
||||
connected, followed by the string "=>". For example,
|
||||
connected, followed by the string <literal>=></literal>. For example,
|
||||
<programlisting>
|
||||
$ <userinput>psql testdb</userinput>
|
||||
Welcome to psql, the PostgreSQL interactive terminal.
|
||||
|
@ -1152,7 +1152,7 @@ lo_import 152801
|
|||
|
||||
<para>
|
||||
<programlisting>
|
||||
test=> <userinput>\z</userinput>
|
||||
test=> <userinput>\z</userinput>
|
||||
Access permissions for database "test"
|
||||
Relation | Access permissions
|
||||
----------+-------------------------------------
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.44 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.45 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -268,7 +268,7 @@ where <replaceable class="PARAMETER">from_item</replaceable> can be:
|
|||
specified expressions, keeping only the first row of each set of
|
||||
duplicates. The DISTINCT ON expressions are interpreted using the
|
||||
same rules as for ORDER BY items; see below.
|
||||
Note that "the first row" of each set is unpredictable
|
||||
Note that the <quote>first row</quote> of each set is unpredictable
|
||||
unless <command>ORDER BY</command> is used to ensure that the desired
|
||||
row appears first. For example,
|
||||
<programlisting>
|
||||
|
@ -997,13 +997,13 @@ contains an explicit FROM clause.
|
|||
SELECT Clause
|
||||
</title>
|
||||
<para>
|
||||
In the <acronym>SQL92</acronym> standard, the optional keyword "AS"
|
||||
In the <acronym>SQL92</acronym> standard, the optional keyword <literal>AS</>
|
||||
is just noise and can be
|
||||
omitted without affecting the meaning.
|
||||
The <productname>Postgres</productname> parser requires this keyword when
|
||||
renaming output columns because the type extensibility features lead to
|
||||
parsing ambiguities
|
||||
in this context. "AS" is optional in FROM items, however.</para>
|
||||
in this context. <literal>AS</literal> is optional in FROM items, however.</para>
|
||||
|
||||
<para>
|
||||
The DISTINCT ON phrase is not part of <acronym>SQL92</acronym>.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.15 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/unlisten.sgml,v 1.16 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -95,7 +95,7 @@ UNLISTEN { <replaceable class="PARAMETER">notifyname</replaceable> | * }
|
|||
UNLISTEN cancels any existing registration of the current
|
||||
<productname>Postgres</productname> session as a listener on the notify
|
||||
condition <replaceable class="PARAMETER">notifyname</replaceable>.
|
||||
The special condition wildcard "*" cancels all listener registrations
|
||||
The special condition wildcard <literal>*</literal> cancels all listener registrations
|
||||
for the current session.
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.16 2001/09/03 12:57:50 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/update.sgml,v 1.17 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -152,7 +152,7 @@ UPDATE <replaceable class="parameter">#</replaceable>
|
|||
</title>
|
||||
|
||||
<para>
|
||||
Change word "Drama" with "Dramatic" on column kind:
|
||||
Change word <literal>Drama</> with <literal>Dramatic</> on column <structfield>kind</>:
|
||||
|
||||
<programlisting>
|
||||
UPDATE films
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.16 2001/09/12 01:22:25 ishii Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/rules.sgml,v 1.17 2001/09/13 15:55:23 petere Exp $ -->
|
||||
|
||||
<Chapter Id="rules">
|
||||
<Title>The <ProductName>Postgres</ProductName> Rule System</Title>
|
||||
|
@ -30,7 +30,7 @@
|
|||
</Para>
|
||||
|
||||
<Para>
|
||||
The query rewrite rule system (the "rule system" from now on)
|
||||
The query rewrite rule system (the <firstterm>rule system</> from now on)
|
||||
is totally different from stored procedures and triggers.
|
||||
It modifies queries to
|
||||
take rules into consideration, and then passes the modified
|
||||
|
@ -495,7 +495,7 @@
|
|||
|
||||
It's the simplest SELECT Al can do on our views, so we take this
|
||||
to explain the basics of view rules.
|
||||
The 'SELECT * FROM shoelace' was interpreted by the parser and
|
||||
The <literal>SELECT * FROM shoelace</literal> was interpreted by the parser and
|
||||
produced the parsetree
|
||||
|
||||
<ProgramListing>
|
||||
|
@ -664,7 +664,7 @@
|
|||
</ProgramListing>
|
||||
|
||||
It turns out that the planner will collapse this tree into a two-level
|
||||
query tree: the bottommost selects will be "pulled up" into the middle
|
||||
query tree: the bottommost selects will be <quote>pulled up</quote> into the middle
|
||||
select since there's no need to process them separately. But the
|
||||
middle select will remain separate from the top, because it contains
|
||||
aggregate functions. If we pulled those up it would change the behavior
|
||||
|
@ -912,7 +912,7 @@
|
|||
</ProgramListing>
|
||||
|
||||
in mind.
|
||||
In the following, "update rules" means rules that are defined
|
||||
In the following, <firstterm>update rules</> means rules that are defined
|
||||
ON INSERT, UPDATE or DELETE.
|
||||
</Para>
|
||||
|
||||
|
@ -1111,7 +1111,7 @@
|
|||
WHERE bpchareq(shoelace_data.sl_name, 'sl7');</FirstTerm>
|
||||
</ProgramListing>
|
||||
|
||||
There is a rule 'log_shoelace' that is ON UPDATE with the rule
|
||||
There is a rule <literal>log_shoelace</literal> that is ON UPDATE with the rule
|
||||
qualification expression
|
||||
|
||||
<ProgramListing>
|
||||
|
@ -1451,7 +1451,7 @@
|
|||
FROM shoelace_arrive shoelace_arrive, shoelace_ok shoelace_ok;
|
||||
</ProgramListing>
|
||||
|
||||
Now the first rule 'shoelace_ok_ins' is applied and turns it
|
||||
Now the first rule <literal>shoelace_ok_ins</literal> is applied and turns it
|
||||
into
|
||||
|
||||
<ProgramListing>
|
||||
|
@ -1765,7 +1765,7 @@ Merge Join
|
|||
hole, but in fact it isn't. If this would not work, the secretary
|
||||
could setup a table with the same columns as phone_number and
|
||||
copy the data to there once per day. Then it's his own data and
|
||||
he can grant access to everyone he wants. A GRANT means "I trust you".
|
||||
he can grant access to everyone he wants. A GRANT means <quote>I trust you</quote>.
|
||||
If someone you trust does the thing above, it's time to
|
||||
think it over and then REVOKE.
|
||||
</Para>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.78 2001/09/12 14:06:37 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.79 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="runtime">
|
||||
|
@ -132,7 +132,7 @@ NOTICE: Initializing database with en_US collation order.
|
|||
will cause indexes to be sorted in an order that prevents them from
|
||||
being used for LIKE and regular-expression searches. If you need
|
||||
good performance of such searches, you should set your current locale
|
||||
to "C" and re-run <command>initdb</command>. On most systems, setting the
|
||||
to <literal>C</> and re-run <command>initdb</command>. On most systems, setting the
|
||||
current locale is done by changing the value of the environment variable
|
||||
<literal>LC_ALL</literal> or <literal>LANG</literal>. The sort order used
|
||||
within a particular database cluster is set by <command>initdb</command>
|
||||
|
|
|
@ -955,8 +955,8 @@ char *<REPLACEABLE CLASS="PARAMETER">nulls</REPLACEABLE>
|
|||
<PARA>
|
||||
Array describing what parameters get NULLs
|
||||
<SimpleList>
|
||||
<Member>'n' indicates NULL allowed</Member>
|
||||
<Member>' ' indicates NULL not allowed</Member>
|
||||
<Member><literal>n</literal> indicates NULL allowed</Member>
|
||||
<Member>A space indicates NULL not allowed</Member>
|
||||
</SimpleList>
|
||||
</PARA>
|
||||
</LISTITEM>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.46 2001/09/09 17:21:59 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.47 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
|
@ -414,7 +414,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
|||
where <replaceable>delim</replaceable> is the delimiter character
|
||||
for the type, as recorded in its <literal>pg_type</literal>
|
||||
entry. (For all built-in types, this is the comma character
|
||||
",".) Each <replaceable>val</replaceable> is either a constant
|
||||
<quote><literal>,</literal></>.) Each <replaceable>val</replaceable> is either a constant
|
||||
of the array element type, or a sub-array. An example of an
|
||||
array constant is
|
||||
<programlisting>
|
||||
|
@ -461,7 +461,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
"$" (dollar) cannot be a single-character operator, although it
|
||||
<literal>$</> (dollar) cannot be a single-character operator, although it
|
||||
can be part of a multiple-character operator name.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -476,7 +476,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
A multiple-character operator name cannot end in "+" or "-",
|
||||
A multiple-character operator name cannot end in <literal>+</> or <literal>-</>,
|
||||
unless the name also contains at least one of these characters:
|
||||
<literallayout>
|
||||
~ ! @ # % ^ & | ` ? $
|
||||
|
@ -493,7 +493,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
|
|||
<para>
|
||||
When working with non-SQL-standard operator names, you will usually
|
||||
need to separate adjacent operators with spaces to avoid ambiguity.
|
||||
For example, if you have defined a left-unary operator named "@",
|
||||
For example, if you have defined a left-unary operator named <literal>@</literal>,
|
||||
you cannot write <literal>X*@Y</literal>; you must write
|
||||
<literal>X* @Y</literal> to ensure that
|
||||
<productname>Postgres</productname> reads it as two operator names
|
||||
|
@ -1016,8 +1016,8 @@ sqrt(2)
|
|||
The precedence and associativity of the operators is hard-wired
|
||||
into the parser. Most operators have the same precedence and are
|
||||
left-associative. This may lead to non-intuitive behavior; for
|
||||
example the Boolean operators "<" and ">" have a different
|
||||
precedence than the Boolean operators "<=" and ">=". Also,
|
||||
example the Boolean operators <literal><</> and <literal>></> have a different
|
||||
precedence than the Boolean operators <literal><=</> and <literal>>=</>. Also,
|
||||
you will sometimes need to add parentheses when using combinations
|
||||
of binary and unary operators. For instance
|
||||
<programlisting>
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
<para>
|
||||
The trigger function must be created before the trigger is created as a
|
||||
function taking no arguments and returning opaque. If the function is
|
||||
written in C, it must use the "version 1" function manager interface.
|
||||
written in C, it must use the <quote>version 1</> function manager interface.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -115,7 +115,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
|||
<para>
|
||||
Also, <replaceable>procedure</replaceable>
|
||||
may be used for triggering different relations (these
|
||||
functions are named as "general trigger functions").
|
||||
functions are named as <firstterm>general trigger functions</>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -123,7 +123,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
|||
function that takes as its arguments two field names and puts the current
|
||||
user in one and the current timestamp in the other. This allows triggers to
|
||||
be written on INSERT events to automatically track creation of records in a
|
||||
transaction table for example. It could also be used as a "last updated"
|
||||
transaction table for example. It could also be used as a <quote>last updated</>
|
||||
function if used in an UPDATE event.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -197,7 +197,7 @@ CREATE TRIGGER <replaceable>trigger</replaceable> [ BEFORE | AFTER ] [ INSERT |
|
|||
|
||||
<para>
|
||||
When a function is called by the trigger manager, it is not passed any
|
||||
normal parameters, but it is passed a "context" pointer pointing to a
|
||||
normal parameters, but it is passed a <quote>context</> pointer pointing to a
|
||||
TriggerData structure. C functions can check whether they were called
|
||||
from the trigger manager or not by executing the macro
|
||||
<literal>CALLED_AS_TRIGGER(fcinfo)</literal>, which expands to
|
||||
|
|
|
@ -178,7 +178,7 @@ Implicit conversions should never have surprising or unpredictable outcomes.
|
|||
<listitem>
|
||||
<para>
|
||||
User-defined types, of which the parser has no a-priori knowledge, should be
|
||||
"higher" in the type hierarchy. In mixed-type expressions, native types shall always
|
||||
<quote>higher</quote> in the type hierarchy. In mixed-type expressions, native types shall always
|
||||
be converted to a user-defined type (of course, only if conversion is necessary).
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -393,7 +393,7 @@ are specified in the query. So, the parser looks for all candidate operators
|
|||
and finds that there are candidates accepting both string-category and
|
||||
bit-string-category inputs. Since string category is preferred when available,
|
||||
that category is selected, and then the
|
||||
"preferred type" for strings, <type>text</type>, is used as the specific
|
||||
<quote>preferred type</quote> for strings, <type>text</type>, is used as the specific
|
||||
type to resolve the unknown literals to.
|
||||
</para>
|
||||
</sect3>
|
||||
|
@ -483,9 +483,9 @@ If only one candidate remains, use it; else continue to the next step.
|
|||
</step>
|
||||
<step performance="required">
|
||||
<para>
|
||||
If any input arguments are "unknown", check the type categories accepted
|
||||
If any input arguments are <type>unknown</type>, check the type categories accepted
|
||||
at those argument positions by the remaining candidates. At each position,
|
||||
select "string"
|
||||
select <type>string</type>
|
||||
category if any candidate accepts that category (this bias towards string
|
||||
is appropriate since an unknown-type literal does look like a string).
|
||||
Otherwise, if all the remaining candidates accept the same type category,
|
||||
|
@ -592,7 +592,7 @@ tgl=> select substr(text(varchar '1234'), 3);
|
|||
<note>
|
||||
<para>
|
||||
Actually, the parser is aware that <type>text</type> and <type>varchar</type>
|
||||
are "binary compatible", meaning that one can be passed to a function that
|
||||
are <firstterm>binary compatible</>, meaning that one can be passed to a function that
|
||||
accepts the other without doing any physical conversion. Therefore, no
|
||||
explicit type conversion call is really inserted in this case.
|
||||
</para>
|
||||
|
@ -746,7 +746,7 @@ tgl=> SELECT text 'a' AS "Text" UNION SELECT 'b';
|
|||
b
|
||||
(2 rows)
|
||||
</programlisting>
|
||||
Here, the unknown-type literal 'b' will be resolved as type text.
|
||||
Here, the unknown-type literal <literal>'b'</literal> will be resolved as type text.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.13 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.14 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xaggr">
|
||||
|
@ -36,8 +36,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.13 2001/09/10 21:58:47 peter
|
|||
<para>
|
||||
If we define an aggregate that does not use a final function,
|
||||
we have an aggregate that computes a running function of
|
||||
the column values from each row. "Sum" is an
|
||||
example of this kind of aggregate. "Sum" starts at
|
||||
the column values from each row. <function>Sum</> is an
|
||||
example of this kind of aggregate. <function>Sum</> starts at
|
||||
zero and always adds the current row's value to
|
||||
its running total. For example, if we want to make a Sum
|
||||
aggregate to work on a data type for complex numbers,
|
||||
|
@ -61,30 +61,30 @@ SELECT complex_sum(a) FROM test_complex;
|
|||
+------------+
|
||||
</programlisting>
|
||||
|
||||
(In practice, we'd just name the aggregate "sum", and rely on
|
||||
(In practice, we'd just name the aggregate <function>sum</function>, and rely on
|
||||
<productname>Postgres</productname> to figure out which kind
|
||||
of sum to apply to a complex column.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The above definition of "Sum" will return zero (the initial
|
||||
The above definition of <function>Sum</function> will return zero (the initial
|
||||
state condition) if there are no non-null input values.
|
||||
Perhaps we want to return NULL in that case instead --- SQL92
|
||||
expects "Sum" to behave that way. We can do this simply by
|
||||
expects <function>Sum</function> to behave that way. We can do this simply by
|
||||
omitting the <literal>initcond</literal> phrase, so that the initial state
|
||||
condition is NULL. Ordinarily this would mean that the <literal>sfunc</literal>
|
||||
would need to check for a NULL state-condition input, but for
|
||||
"Sum" and some other simple aggregates like "Max" and "Min",
|
||||
<function>Sum</function> and some other simple aggregates like <function>Max</> and <function>Min</>,
|
||||
it's sufficient to insert the first non-null input value into
|
||||
the state variable and then start applying the transition function
|
||||
at the second non-null input value. <productname>Postgres</productname>
|
||||
will do that automatically if the initial condition is NULL and
|
||||
the transition function is marked "strict" (i.e., not to be called
|
||||
the transition function is marked <quote>strict</> (i.e., not to be called
|
||||
for NULL inputs).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another bit of default behavior for a "strict" transition function
|
||||
Another bit of default behavior for a <quote>strict</> transition function
|
||||
is that the previous state value is retained unchanged whenever a
|
||||
NULL input value is encountered. Thus, NULLs are ignored. If you
|
||||
need some other behavior for NULL inputs, just define your transition
|
||||
|
@ -93,7 +93,7 @@ SELECT complex_sum(a) FROM test_complex;
|
|||
</para>
|
||||
|
||||
<para>
|
||||
"Average" is a more complex example of an aggregate. It requires
|
||||
<function>Average</> is a more complex example of an aggregate. It requires
|
||||
two pieces of running state: the sum of the inputs and the count
|
||||
of the number of inputs. The final result is obtained by dividing
|
||||
these quantities. Average is typically implemented by using a
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.35 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.36 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="xfunc">
|
||||
|
@ -71,7 +71,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xfunc.sgml,v 1.35 2001/09/10 21:58:47 peter
|
|||
Arguments to the SQL function may be referenced in the queries using
|
||||
a $n syntax: $1 refers to the first argument, $2 to the second, and so
|
||||
on. If an argument is complex, then a <firstterm>dot</firstterm>
|
||||
notation (e.g. "$1.emp") may be
|
||||
notation (e.g. <literal>$1.emp</literal>) may be
|
||||
used to access attributes of the argument or
|
||||
to invoke functions.
|
||||
</para>
|
||||
|
@ -381,11 +381,11 @@ SELECT clean_EMP();
|
|||
|
||||
<para>
|
||||
Two different calling conventions are currently used for C functions.
|
||||
The newer "version 1" calling convention is indicated by writing
|
||||
The newer <quote>version 1</quote> calling convention is indicated by writing
|
||||
a <literal>PG_FUNCTION_INFO_V1()</literal> macro call for the function,
|
||||
as illustrated below. Lack of such a macro indicates an old-style
|
||||
("version 0") function. The language name specified in CREATE FUNCTION
|
||||
is 'C' in either case. Old-style functions are now deprecated
|
||||
("version 0") function. The language name specified in <command>CREATE FUNCTION</command>
|
||||
is <literal>C</literal> in either case. Old-style functions are now deprecated
|
||||
because of portability problems and lack of functionality, but they
|
||||
are still supported for compatibility reasons.
|
||||
</para>
|
||||
|
@ -496,7 +496,7 @@ SELECT clean_EMP();
|
|||
|
||||
<para>
|
||||
The following table gives the C type required for parameters in the C
|
||||
functions that will be loaded into Postgres. The "Defined In"
|
||||
functions that will be loaded into Postgres. The <quote>Defined In</quote>
|
||||
column gives the actual header file (in the
|
||||
<filename>.../src/backend/</filename>
|
||||
directory) that the equivalent C type is defined. Note that you should
|
||||
|
@ -654,7 +654,7 @@ SELECT clean_EMP();
|
|||
|
||||
<para>
|
||||
Internally, <productname>Postgres</productname> regards a
|
||||
base type as a "blob of memory." The user-defined
|
||||
base type as a <quote>blob of memory</quote>. The user-defined
|
||||
functions that you define over a type in turn define the
|
||||
way that <productname>Postgres</productname> can operate
|
||||
on it. That is, <productname>Postgres</productname> will
|
||||
|
@ -894,7 +894,7 @@ CREATE FUNCTION concat_text(text, text) RETURNS text
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Notice that we have specified the functions as "strict", meaning that
|
||||
Notice that we have specified the functions as <quote>strict</quote>, meaning that
|
||||
the system should automatically assume a NULL result if any input
|
||||
value is NULL. By doing this, we avoid having to check for NULL inputs
|
||||
in the function code. Without this, we'd have to check for NULLs
|
||||
|
@ -929,7 +929,7 @@ PG_FUNCTION_INFO_V1(funcname);
|
|||
</programlisting>
|
||||
must appear in the same source file (conventionally it's written
|
||||
just before the function itself). This macro call is not needed
|
||||
for "internal"-language functions, since Postgres currently assumes
|
||||
for <literal>internal</>-language functions, since Postgres currently assumes
|
||||
all internal functions are version-1. However, it is
|
||||
<emphasis>required</emphasis> for dynamically-loaded functions.
|
||||
</para>
|
||||
|
@ -1045,7 +1045,7 @@ concat_text(PG_FUNCTION_ARGS)
|
|||
An example is that in coding add_one_float8, we no longer need to
|
||||
be aware that float8 is a pass-by-reference type. Another
|
||||
example is that the GETARG macros for variable-length types hide
|
||||
the need to deal with fetching "toasted" (compressed or
|
||||
the need to deal with fetching <quote>toasted</quote> (compressed or
|
||||
out-of-line) values. The old-style <function>copytext</function>
|
||||
and <function>concat_text</function> functions shown above are
|
||||
actually wrong in the presence of toasted values, because they
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.18 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.19 2001/09/13 15:55:23 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
|
@ -123,7 +123,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
|||
impose a strict ordering on keys, lesser to greater. Since
|
||||
<productname>Postgres</productname> allows the user to define operators,
|
||||
<productname>Postgres</productname> cannot look at the name of an operator
|
||||
(e.g., ">" or "<") and tell what kind of comparison it is. In fact,
|
||||
(e.g., <literal>></> or <literal><</>) and tell what kind of comparison it is. In fact,
|
||||
some access methods don't impose any ordering at all. For example,
|
||||
<acronym>R-tree</acronym>s express a rectangle-containment relationship,
|
||||
whereas a hashed data structure expresses only bitwise similarity based
|
||||
|
@ -131,7 +131,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
|||
needs some consistent way of taking a qualification in your query,
|
||||
looking at the operator and then deciding if a usable index exists. This
|
||||
implies that <productname>Postgres</productname> needs to know, for
|
||||
example, that the "<=" and ">" operators partition a
|
||||
example, that the <literal><=</> and <literal>></> operators partition a
|
||||
<acronym>B-tree</acronym>. <productname>Postgres</productname>
|
||||
uses strategies to express these relationships between
|
||||
operators and the way they can be used to scan indexes.
|
||||
|
@ -240,7 +240,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
|||
does, <filename>amorderstrategy</filename> is the number of the strategy
|
||||
routine that corresponds to the ordering operator. For example, B-tree
|
||||
has <filename>amorderstrategy</filename> = 1 which is its
|
||||
"less than" strategy number.
|
||||
<quote>less than</quote> strategy number.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -388,7 +388,7 @@ CREATE FUNCTION complex_abs_eq(complex, complex)
|
|||
|
||||
<para>
|
||||
The final routine in the
|
||||
file is the "support routine" mentioned when we discussed the amsupport
|
||||
file is the <quote>support routine</quote> mentioned when we discussed the amsupport
|
||||
column of the <filename>pg_am</filename> table. We will use this
|
||||
later on. For now, ignore it.
|
||||
</para>
|
||||
|
@ -463,10 +463,11 @@ CREATE OPERATOR = (
|
|||
c.oprname = '<';
|
||||
</programlisting>
|
||||
|
||||
Now do this for the other operators substituting for the "1" in the
|
||||
second line above and the "<" in the last line. Note the order:
|
||||
"less than" is 1, "less than or equal" is 2, "equal" is 3, "greater
|
||||
than or equal" is 4, and "greater than" is 5.
|
||||
Now do this for the other operators substituting for the <literal>1</> in the
|
||||
second line above and the <literal><</> in the last line. Note the order:
|
||||
<quote>less than</> is 1, <quote>less than or equal</> is 2,
|
||||
<quote>equal</> is 3, <quote>greater than or equal</quote> is 4, and
|
||||
<quote>greater than</quote> is 5.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -475,7 +476,7 @@ CREATE OPERATOR = (
|
|||
</para>
|
||||
|
||||
<para>
|
||||
The final step is registration of the "support routine" previously
|
||||
The final step is registration of the <quote>support routine</quote> previously
|
||||
described in our discussion of <filename>pg_am</filename>. The
|
||||
<filename>oid</filename> of this support routine is stored in the
|
||||
<filename>pg_amproc</filename> table, keyed by the operator class
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.13 2001/09/10 21:58:47 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.14 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<Chapter Id="xoper">
|
||||
|
@ -19,7 +19,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/xoper.sgml,v 1.13 2001/09/10 21:58:47 peter
|
|||
</Para>
|
||||
|
||||
<Para>
|
||||
Every operator is "syntactic sugar" for a call to an
|
||||
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
|
||||
the operator. However, an operator is <emphasis>not</emphasis>
|
||||
|
@ -113,9 +113,9 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
commutator of the operator being defined. We say that operator A is the
|
||||
commutator of operator B if (x A y) equals (y B x) for all possible input
|
||||
values x,y. Notice that B is also the commutator of A. For example,
|
||||
operators '<' and '>' for a particular data type are usually each others'
|
||||
commutators, and operator '+' is usually commutative with itself.
|
||||
But operator '-' is usually not commutative with anything.
|
||||
operators <literal><</> and <literal>></> for a particular data type are usually each others'
|
||||
commutators, and operator <literal>+</> is usually commutative with itself.
|
||||
But operator <literal>-</> is usually not commutative with anything.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -176,7 +176,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
is the negator of operator B if both return boolean results and
|
||||
(x A y) equals NOT (x B y) for all possible inputs x,y.
|
||||
Notice that B is also the negator of A.
|
||||
For example, '<' and '>=' are a negator pair for most data types.
|
||||
For example, <literal><</> and <literal>>=</> are a negator pair for most data types.
|
||||
An operator can never be validly be its own negator.
|
||||
</para>
|
||||
|
||||
|
@ -239,16 +239,16 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
scalargtsel for > or >=
|
||||
</ProgramListing>
|
||||
It might seem a little odd that these are the categories, but they
|
||||
make sense if you think about it. '=' will typically accept only
|
||||
a small fraction of the rows in a table; '<>' will typically reject
|
||||
only a small fraction. '<' will accept a fraction that depends on
|
||||
make sense if you think about it. <literal>=</> will typically accept only
|
||||
a small fraction of the rows in a table; <literal><></> will typically reject
|
||||
only a small fraction. <literal><</> will accept a fraction that depends on
|
||||
where the given constant falls in the range of values for that table
|
||||
column (which, it just so happens, is information collected by
|
||||
<command>ANALYZE</command> and made available to the selectivity estimator).
|
||||
'<=' will accept a slightly larger fraction than '<' for the same
|
||||
<literal><=</> will accept a slightly larger fraction than <literal><</> for the same
|
||||
comparison constant, but they're close enough to not be worth
|
||||
distinguishing, especially since we're not likely to do better than a
|
||||
rough guess anyhow. Similar remarks apply to '>' and '>='.
|
||||
rough guess anyhow. Similar remarks apply to <literal>></> and <literal>>=</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -339,7 +339,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
time intervals is not bitwise equality; the interval equality operator
|
||||
considers two time intervals equal if they have the same
|
||||
duration, whether or not their endpoints are identical. What this means
|
||||
is that a join using "=" between interval fields would yield different
|
||||
is that a join using <literal>=</literal> between interval fields would yield different
|
||||
results if implemented as a hash join than if implemented another way,
|
||||
because a large fraction of the pairs that should match will hash to
|
||||
different values and will never be compared by the hash join. But
|
||||
|
@ -386,7 +386,7 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
Merge join is based on the idea of sorting the left and righthand tables
|
||||
into order and then scanning them in parallel. So, both data types must
|
||||
be capable of being fully ordered, and the join operator must be one
|
||||
that can only succeed for pairs of values that fall at the "same place"
|
||||
that can only succeed for pairs of values that fall at the <quote>same place</>
|
||||
in the sort order. In practice this means that the join operator must
|
||||
behave like equality. But unlike hashjoin, where the left and right
|
||||
data types had better be the same (or at least bitwise equivalent),
|
||||
|
@ -410,8 +410,8 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
</para>
|
||||
|
||||
<para>
|
||||
In practice you should only write SORT clauses for an '=' operator,
|
||||
and the two referenced operators should always be named '<'. Trying
|
||||
In practice you should only write SORT clauses for an <literal>=</> operator,
|
||||
and the two referenced operators should always be named <literal><</>. Trying
|
||||
to use merge join with operators named anything else will result in
|
||||
hopeless confusion, for reasons we'll see in a moment.
|
||||
</para>
|
||||
|
@ -433,9 +433,9 @@ SELECT (a + b) AS c FROM test_complex;
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
There must be '<' and '>' ordering operators having the same left and
|
||||
There must be <literal><</> and <literal>></> ordering operators having the same left and
|
||||
right input data types as the mergejoinable operator itself. These
|
||||
operators <emphasis>must</emphasis> be named '<' and '>'; you do
|
||||
operators <emphasis>must</emphasis> be named <literal><</> and <literal>></>; you do
|
||||
not have any choice in the matter, since there is no provision for
|
||||
specifying them explicitly. Note that if the left and right data types
|
||||
are different, neither of these operators is the same as either
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.10 2001/03/24 23:03:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.11 2001/09/13 15:55:23 petere Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="y2k">
|
||||
|
@ -51,15 +51,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/y2k.sgml,v 1.10 2001/03/24 23:03:26 p
|
|||
are documented in the current <citetitle>User's Guide</citetitle>
|
||||
in the chapter on data types.
|
||||
For two-digit years, the significant transition year is 1970, not 2000;
|
||||
e.g. "<literal>70-01-01</literal>" is interpreted as 1970-01-01,
|
||||
whereas "<literal>69-01-01</literal>" is interpreted as 2069-01-01.
|
||||
e.g. <literal>70-01-01</literal> is interpreted as 1970-01-01,
|
||||
whereas <literal>69-01-01</literal> is interpreted as 2069-01-01.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Any Y2K problems in the underlying OS related to obtaining "the
|
||||
current time" may propagate into apparent Y2K problems in
|
||||
Any Y2K problems in the underlying OS related to obtaining the
|
||||
<quote>current time</quote> may propagate into apparent Y2K problems in
|
||||
<productname>Postgres</productname>.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
Loading…
Reference in New Issue