mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-15 08:20:16 +08:00
Replace "--" and "---" with "—" as appropriate, for better-looking
output.
This commit is contained in:
parent
db1531f6d8
commit
ec7a6bd9a2
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.45 2004/08/08 21:33:11 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.46 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-advanced">
|
||||
@ -439,9 +439,9 @@ SELECT name, altitude
|
||||
indicates that the query should be run over only the
|
||||
<classname>cities</classname> table, and not tables below
|
||||
<classname>cities</classname> in the inheritance hierarchy. Many
|
||||
of the commands that we have already discussed --
|
||||
of the commands that we have already discussed —
|
||||
<command>SELECT</command>, <command>UPDATE</command>, and
|
||||
<command>DELETE</command> -- support this <literal>ONLY</literal>
|
||||
<command>DELETE</command> — support this <literal>ONLY</literal>
|
||||
notation.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.38 2004/08/08 05:55:55 joe Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.39 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<sect1 id="arrays">
|
||||
<title>Arrays</title>
|
||||
@ -49,7 +49,7 @@ CREATE TABLE tictactoe (
|
||||
</programlisting>
|
||||
|
||||
However, the current implementation does not enforce the array size
|
||||
limits --- the behavior is the same as for arrays of unspecified
|
||||
limits — the behavior is the same as for arrays of unspecified
|
||||
length.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.50 2004/11/14 06:10:12 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.51 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
@ -499,7 +499,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
the administrator specify a shell command to be executed to copy a
|
||||
completed segment file to wherever it needs to go. The command could be
|
||||
as simple as a <application>cp</>, or it could invoke a complex shell
|
||||
script --- it's all up to you.
|
||||
script — it's all up to you.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -725,7 +725,7 @@ SELECT pg_stop_backup();
|
||||
last base backup, the interval between base backups should usually be
|
||||
chosen based on how much storage you want to expend on archived WAL
|
||||
files. You should also consider how long you are prepared to spend
|
||||
recovering, if recovery should be necessary --- the system will have to
|
||||
recovering, if recovery should be necessary — the system will have to
|
||||
replay all those WAL segments, and that could take awhile if it has
|
||||
been a long time since the last base backup.
|
||||
</para>
|
||||
|
@ -1,6 +1,6 @@
|
||||
<!--
|
||||
Documentation of the system catalogs, directed toward PostgreSQL developers
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.91 2004/11/05 19:15:48 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.92 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="catalogs">
|
||||
@ -16,7 +16,7 @@
|
||||
Normally, one should not change the system catalogs by hand, there
|
||||
are always SQL commands to do that. (For example, <command>CREATE
|
||||
DATABASE</command> inserts a row into the
|
||||
<structname>pg_database</structname> catalog --- and actually
|
||||
<structname>pg_database</structname> catalog — and actually
|
||||
creates the database on disk.) There are some exceptions for
|
||||
particularly esoteric operations, such as adding index access methods.
|
||||
</para>
|
||||
@ -2509,7 +2509,7 @@
|
||||
not in its <structname>pg_opclass</structname> row, but in the associated
|
||||
rows in <structname>pg_amop</structname> and
|
||||
<structname>pg_amproc</structname>. Those rows are considered to be
|
||||
part of the operator class definition --- this is not unlike the way
|
||||
part of the operator class definition — this is not unlike the way
|
||||
that a relation is defined by a single <structname>pg_class</structname>
|
||||
row plus associated rows in <structname>pg_attribute</structname> and
|
||||
other tables.
|
||||
@ -4275,7 +4275,7 @@
|
||||
<para>
|
||||
<structname>pg_stats</structname> is also designed to present the
|
||||
information in a more readable format than the underlying catalog
|
||||
--- at the cost that its schema must be extended whenever new slot types
|
||||
— at the cost that its schema must be extended whenever new slot types
|
||||
are defined for <structname>pg_statistic</structname>.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.45 2004/09/17 21:59:56 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.46 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<chapter id="charset">
|
||||
<title>Localization</>
|
||||
@ -829,12 +829,13 @@ RESET client_encoding;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the conversion of a particular character is not possible --
|
||||
suppose you chose <literal>EUC_JP</literal> for the server and
|
||||
<literal>LATIN1</literal> for the client, then some Japanese
|
||||
characters cannot be converted to <literal>LATIN1</literal> -- it
|
||||
is transformed to its hexadecimal byte values in parentheses,
|
||||
e.g., <literal>(826C)</literal>.
|
||||
If the conversion of a particular character is not possible
|
||||
— suppose you chose <literal>EUC_JP</literal> for the
|
||||
server and <literal>LATIN1</literal> for the client, then some
|
||||
Japanese characters cannot be converted to
|
||||
<literal>LATIN1</literal> — it is transformed to its
|
||||
hexadecimal byte values in parentheses, e.g.,
|
||||
<literal>(826C)</literal>.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.67 2004/11/10 21:54:23 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.68 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
@ -14,7 +14,7 @@ $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.67 2004/11/10 21:54:23 pete
|
||||
specifies which <productname>PostgreSQL</productname> user name it
|
||||
wants to connect as, much the same way one logs into a Unix computer
|
||||
as a particular user. Within the SQL environment the active database
|
||||
user name determines access privileges to database objects -- see
|
||||
user name determines access privileges to database objects — see
|
||||
<xref linkend="user-manag"> for more information. Therefore, it is
|
||||
essential to restrict which database users can connect.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.42 2004/08/10 00:55:03 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.43 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<appendix id="datetime-appendix">
|
||||
@ -370,7 +370,7 @@ $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.42 2004/08/10 00:55:03 tgl Exp
|
||||
<xref linkend="datetime-timezone-input-table"> shows the time zone
|
||||
abbreviations recognized by <productname>PostgreSQL</productname>
|
||||
in date/time input values. Note that these names are <emphasis>not</>
|
||||
used for date/time output --- display is driven by the currently
|
||||
used for date/time output — display is driven by the currently
|
||||
selected <xref linkend="guc-timezone"> parameter setting. (It is
|
||||
likely that future releases will make some use of <varname>timezone</>
|
||||
for input as well.)
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.31 2004/10/21 21:33:59 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.32 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<chapter id="ddl">
|
||||
<title>Data Definition</title>
|
||||
@ -350,7 +350,7 @@ DROP TABLE products;
|
||||
identifiers are also 32-bit quantities. This creates a hard limit
|
||||
of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
|
||||
within a single transaction. In practice this limit is not a
|
||||
problem --- note that the limit is on number of
|
||||
problem — note that the limit is on number of
|
||||
<acronym>SQL</acronym> commands, not number of rows processed.
|
||||
</para>
|
||||
</sect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/dfunc.sgml,v 1.27 2003/11/29 19:51:36 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/dfunc.sgml,v 1.28 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect2 id="dfunc">
|
||||
@ -38,8 +38,8 @@ $PostgreSQL: pgsql/doc/src/sgml/dfunc.sgml,v 1.27 2003/11/29 19:51:36 pgsql Exp
|
||||
in memory when they are loaded by the executable. (Object files
|
||||
intended for executables are usually not compiled that way.) The
|
||||
command to link a shared library contains special flags to
|
||||
distinguish it from linking an executable. --- At least this is the
|
||||
theory. On some systems the practice is much uglier.
|
||||
distinguish it from linking an executable (at least in theory
|
||||
— on some systems the practice is much uglier).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.50 2004/02/17 02:53:03 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/docguide.sgml,v 1.51 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<appendix id="docguide">
|
||||
<title>Documentation</title>
|
||||
@ -88,7 +88,7 @@
|
||||
This is the definition of DocBook itself. We currently use
|
||||
version 4.2; you cannot use later or earlier versions. Note
|
||||
that there is also an <acronym>XML</acronym> version of DocBook
|
||||
-- do not use that.
|
||||
— do not use that.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.9 2004/10/01 16:39:46 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.10 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<appendix id="errcodes-appendix">
|
||||
<title><productname>PostgreSQL</productname> Error Codes</title>
|
||||
@ -125,7 +125,7 @@
|
||||
|
||||
<row>
|
||||
<entry>Class 02</entry>
|
||||
<entry>No Data --- this is also a warning class per SQL99</entry>
|
||||
<entry>No Data — this is also a warning class per SQL99</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.222 2004/11/08 15:57:05 petere Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.223 2004/11/15 06:32:13 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -2793,7 +2793,7 @@ substring('foobar' from '#"o_b#"%' for '#') <lineannotation>NULL</lineannotat
|
||||
if it is a member of the regular set described by the regular
|
||||
expression. As with <function>LIKE</function>, pattern characters
|
||||
match string characters exactly unless they are special characters
|
||||
in the regular expression language --- but regular expressions use
|
||||
in the regular expression language — but regular expressions use
|
||||
different special characters than <function>LIKE</function> does.
|
||||
Unlike <function>LIKE</function> patterns, a
|
||||
regular expression is allowed to match anywhere within a string, unless
|
||||
@ -8425,7 +8425,7 @@ SELECT relname FROM pg_class WHERE pg_table_is_visible(oid);
|
||||
SELECT pg_type_is_visible('myschema.widget'::regtype);
|
||||
</programlisting>
|
||||
Note that it would not make much sense to test an unqualified name in
|
||||
this way --- if the name can be recognized at all, it must be visible.
|
||||
this way — if the name can be recognized at all, it must be visible.
|
||||
</para>
|
||||
|
||||
<indexterm zone="functions-info">
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.17 2004/06/13 17:51:08 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/information_schema.sgml,v 1.18 2004/11/15 06:32:13 neilc Exp $ -->
|
||||
|
||||
<chapter id="information-schema">
|
||||
<title>The Information Schema</title>
|
||||
@ -11,7 +11,7 @@
|
||||
The information schema consists of a set of views that contain
|
||||
information about the objects defined in the current database. The
|
||||
information schema is defined in the SQL standard and can therefore
|
||||
be expected to be portable and remain stable --- unlike the system
|
||||
be expected to be portable and remain stable — unlike the system
|
||||
catalogs, which are specific to
|
||||
<productname>PostgreSQL</productname> and are modelled after
|
||||
implementation concerns. The information schema views do not,
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.167 2004/10/30 23:09:59 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.168 2004/11/15 06:32:13 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="libpq">
|
||||
@ -2252,7 +2252,7 @@ unsigned char *PQescapeBytea(const unsigned char *from,
|
||||
<listitem>
|
||||
<para>
|
||||
Converts an escaped string representation of binary data into binary
|
||||
data --- the reverse of <function>PQescapeBytea</function>.
|
||||
data — the reverse of <function>PQescapeBytea</function>.
|
||||
This is needed when retrieving <type>bytea</type> data in text format,
|
||||
but not when retrieving it in binary format.
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.37 2004/08/05 23:32:10 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.38 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="maintenance">
|
||||
@ -117,7 +117,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.37 2004/08/05 23:32:10 tgl
|
||||
may be useful to set up periodic <application>cron</> tasks that
|
||||
<command>VACUUM</command> only selected tables, skipping tables that are known not to
|
||||
change often. This is only likely to be helpful if you have both
|
||||
large heavily-updated tables and large seldom-updated tables --- the
|
||||
large heavily-updated tables and large seldom-updated tables — the
|
||||
extra cost of vacuuming a small table isn't enough to be worth
|
||||
worrying about.
|
||||
</para>
|
||||
@ -151,7 +151,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.37 2004/08/05 23:32:10 tgl
|
||||
The standard form of <command>VACUUM</> is best used with the goal
|
||||
of maintaining a fairly level steady-state usage of disk space. If
|
||||
you need to return disk space to the operating system you can use
|
||||
<command>VACUUM FULL</> --- but what's the point of releasing disk
|
||||
<command>VACUUM FULL</> — but what's the point of releasing disk
|
||||
space that will only have to be allocated again soon? Moderately
|
||||
frequent standard <command>VACUUM</> runs are a better approach
|
||||
than infrequent <command>VACUUM FULL</> runs for maintaining
|
||||
@ -278,7 +278,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.37 2004/08/05 23:32:10 tgl
|
||||
(32 bits at this writing) a cluster that runs for a long time (more
|
||||
than 4 billion transactions) will suffer <firstterm>transaction ID
|
||||
wraparound</>: the XID counter wraps around to zero, and all of a sudden
|
||||
transactions that were in the past appear to be in the future --- which
|
||||
transactions that were in the past appear to be in the future — which
|
||||
means their outputs become invisible. In short, catastrophic data loss.
|
||||
(Actually the data is still there, but that's cold comfort if you can't
|
||||
get at it.)
|
||||
@ -337,7 +337,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.37 2004/08/05 23:32:10 tgl
|
||||
is exactly one billion transactions: if you wait longer, it's possible
|
||||
that a row version that was not quite old enough to be reassigned last time
|
||||
is now more than two billion transactions old and has wrapped around
|
||||
into the future --- i.e., is lost to you. (Of course, it'll reappear
|
||||
into the future — i.e., is lost to you. (Of course, it'll reappear
|
||||
after another two billion transactions, but that's no help.)
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.44 2004/08/14 22:18:23 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="mvcc">
|
||||
@ -410,7 +410,7 @@ ERROR: could not serialize access due to concurrent update
|
||||
The intuitive meaning (and mathematical definition) of
|
||||
<quote>serializable</> execution is that any two successfully committed
|
||||
concurrent transactions will appear to have executed strictly serially,
|
||||
one after the other --- although which one appeared to occur first may
|
||||
one after the other — although which one appeared to occur first may
|
||||
not be predictable in advance. It is important to realize that forbidding
|
||||
the undesirable behaviors listed in <xref linkend="mvcc-isolevel-table">
|
||||
is not sufficient to guarantee true serializability, and in fact
|
||||
@ -524,7 +524,7 @@ SELECT SUM(value) FROM mytab WHERE class = 2;
|
||||
even if the name contains the word
|
||||
<quote>row</quote>; the names of the lock modes are historical.
|
||||
To some extent the names reflect the typical usage of each lock
|
||||
mode --- but the semantics are all the same. The only real difference
|
||||
mode — but the semantics are all the same. The only real difference
|
||||
between one lock mode and another is the set of lock modes with
|
||||
which each conflicts. Two transactions cannot hold locks of conflicting
|
||||
modes on the same table at the same time. (However, a transaction
|
||||
@ -895,7 +895,7 @@ UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;
|
||||
of transactions not counted by the first. Doing the two sums in a
|
||||
single serializable transaction will give an accurate picture of the
|
||||
effects of transactions that committed before the serializable transaction
|
||||
started --- but one might legitimately wonder whether the answer is still
|
||||
started — but one might legitimately wonder whether the answer is still
|
||||
relevant by the time it is delivered. If the serializable transaction
|
||||
itself applied some changes before trying to make the consistency check,
|
||||
the usefulness of the check becomes even more debatable, since now it
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.9 2003/11/29 19:51:37 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.10 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="nls">
|
||||
@ -18,7 +18,7 @@ $PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.9 2003/11/29 19:51:37 pgsql Exp $
|
||||
<para>
|
||||
<productname>PostgreSQL</>
|
||||
programs (server and client) can issue their messages in
|
||||
your favorite language -- if the messages have been translated.
|
||||
your favorite language — if the messages have been translated.
|
||||
Creating and maintaining translated message sets needs the help of
|
||||
people who speak their own language well and want to contribute to
|
||||
the <productname>PostgreSQL</> effort. You do not have to be a
|
||||
@ -30,7 +30,7 @@ $PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.9 2003/11/29 19:51:37 pgsql Exp $
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>
|
||||
We won't judge your language skills -- this section is about
|
||||
We won't judge your language skills — this section is about
|
||||
software tools. Theoretically, you only need a text editor. But
|
||||
this is only in the unlikely event that you do not want to try out
|
||||
your translated messages. When you configure your source tree, be
|
||||
@ -389,7 +389,7 @@ fprintf(stderr, gettext("panic level %d\n"), lvl);
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
List of provided translations -- empty in the beginning.
|
||||
List of provided translations — initially empty.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.46 2004/05/27 01:00:40 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.47 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="performance-tips">
|
||||
@ -576,7 +576,7 @@ SELECT * FROM a CROSS JOIN b, c, d, e WHERE ...;
|
||||
both for reducing planning time and for directing the planner to a
|
||||
good query plan. If the planner chooses a bad join order by default,
|
||||
you can force it to choose a better order via <literal>JOIN</> syntax
|
||||
--- assuming that you know of a better order, that is. Experimentation
|
||||
— assuming that you know of a better order, that is. Experimentation
|
||||
is recommended.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.48 2004/10/04 05:42:18 neilc Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.49 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -129,7 +129,7 @@ $$ LANGUAGE plpgsql;
|
||||
a parameter as the name of a table or column in an SQL command. To get
|
||||
around this restriction, you can construct dynamic commands using
|
||||
the <application>PL/pgSQL</application> <command>EXECUTE</command>
|
||||
statement --- at the price of constructing a new execution plan on
|
||||
statement — at the price of constructing a new execution plan on
|
||||
every execution.
|
||||
</para>
|
||||
|
||||
@ -499,7 +499,7 @@ $$ LANGUAGE plpgsql;
|
||||
control. <application>PL/pgSQL</>'s <command>BEGIN</>/<command>END</>
|
||||
are only for grouping; they do not start or end a transaction.
|
||||
Functions and trigger procedures are always executed within a transaction
|
||||
established by an outer query --- they cannot start or commit that
|
||||
established by an outer query — they cannot start or commit that
|
||||
transaction, since there would be no context for them to execute in.
|
||||
However, a block containing an <literal>EXCEPTION</> clause effectively
|
||||
forms a subtransaction that can be rolled back without affecting the
|
||||
@ -2359,7 +2359,7 @@ RAISE EXCEPTION 'Nonexistent ID --> %', user_id;
|
||||
<command>CREATE FUNCTION</> command, declaring it as a function with
|
||||
no arguments and a return type of <type>trigger</type>. Note that
|
||||
the function must be declared with no arguments even if it expects
|
||||
to receive arguments specified in <command>CREATE TRIGGER</> ---
|
||||
to receive arguments specified in <command>CREATE TRIGGER</> —
|
||||
trigger arguments are passed via <varname>TG_ARGV</>, as described
|
||||
below.
|
||||
</para>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.54 2004/09/23 23:35:07 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.55 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
|
||||
<chapter id="protocol">
|
||||
<title>Frontend/Backend Protocol</title>
|
||||
@ -775,7 +775,7 @@
|
||||
ErrorResponse, then reads and discards messages until a Sync is reached,
|
||||
then issues ReadyForQuery and returns to normal message processing.
|
||||
(But note that no skipping occurs if an error is detected
|
||||
<emphasis>while</> processing Sync --- this ensures that there is one
|
||||
<emphasis>while</> processing Sync — this ensures that there is one
|
||||
and only one ReadyForQuery sent for each Sync.)
|
||||
</para>
|
||||
|
||||
@ -1034,7 +1034,7 @@
|
||||
value changes for any of the parameters the backend believes the
|
||||
frontend should know about. Most commonly this occurs in response
|
||||
to a <command>SET</> SQL command executed by the frontend, and
|
||||
this case is effectively synchronous --- but it is also possible
|
||||
this case is effectively synchronous — but it is also possible
|
||||
for parameter status changes to occur because the administrator
|
||||
changed a configuration file and then sent the
|
||||
<systemitem>SIGHUP</systemitem> signal to the postmaster. Also,
|
||||
@ -1119,7 +1119,7 @@
|
||||
</para>
|
||||
|
||||
<Para>
|
||||
The cancellation signal may or may not have any effect --- for
|
||||
The cancellation signal may or may not have any effect — for
|
||||
example, if it arrives after the backend has finished processing
|
||||
the query, then it will have no effect. If the cancellation is
|
||||
effective, it results in the current command being terminated
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.30 2004/05/16 23:22:07 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/queries.sgml,v 1.31 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
|
||||
<chapter id="queries">
|
||||
<title>Queries</title>
|
||||
@ -135,7 +135,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
||||
not only that table but all of its subtable successors, unless the
|
||||
key word <literal>ONLY</> precedes the table name. However, the
|
||||
reference produces only the columns that appear in the named table
|
||||
--- any columns added in subtables are ignored.
|
||||
— any columns added in subtables are ignored.
|
||||
</para>
|
||||
|
||||
<sect3 id="queries-join">
|
||||
@ -505,7 +505,7 @@ SELECT * FROM some_very_long_table_name s JOIN another_fairly_long_name a ON s.i
|
||||
|
||||
<para>
|
||||
The alias becomes the new name of the table reference for the
|
||||
current query -- it is no longer possible to refer to the table
|
||||
current query — it is no longer possible to refer to the table
|
||||
by the original name. Thus
|
||||
<programlisting>
|
||||
SELECT * FROM my_table AS m WHERE my_table.a > 5;
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.39 2004/08/30 21:29:12 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.40 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="tutorial-sql">
|
||||
@ -37,7 +37,7 @@ $PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.39 2004/08/30 21:29:12 tgl Exp $
|
||||
</screen>
|
||||
|
||||
This creates the scripts and compiles the C files containing user-defined
|
||||
functions and types. (You must use GNU make for this --- it may be named
|
||||
functions and types. (You must use GNU make for this — it may be named
|
||||
something different on your system, often <application>gmake</>.)
|
||||
Then, to start the tutorial, do the following:
|
||||
|
||||
@ -150,7 +150,7 @@ CREATE TABLE weather (
|
||||
a type for storing single precision floating-point numbers.
|
||||
<type>date</type> should be self-explanatory. (Yes, the column of
|
||||
type <type>date</type> is also named <literal>date</literal>.
|
||||
This may be convenient or confusing -- you choose.)
|
||||
This may be convenient or confusing — you choose.)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.33 2004/08/21 15:45:46 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/cluster.sgml,v 1.34 2004/11/15 06:32:15 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -159,7 +159,7 @@ CREATE TABLE <replaceable class="parameter">newtable</replaceable> AS
|
||||
to rename <replaceable class="parameter">newtable</replaceable> to the old name, and
|
||||
recreate the table's indexes. However, this approach does not preserve
|
||||
OIDs, constraints, foreign key relationships, granted privileges, and
|
||||
other ancillary properties of the table --- all such items must be
|
||||
other ancillary properties of the table — all such items must be
|
||||
manually recreated.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/copy.sgml,v 1.57 2004/04/21 00:34:18 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/copy.sgml,v 1.58 2004/11/15 06:32:15 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -538,7 +538,7 @@ COPY <replaceable class="parameter">tablename</replaceable> [ ( <replaceable cla
|
||||
<term>Signature</term>
|
||||
<listitem>
|
||||
<para>
|
||||
11-byte sequence <literal>PGCOPY\n\377\r\n\0</> --- note that the zero byte
|
||||
11-byte sequence <literal>PGCOPY\n\377\r\n\0</> — note that the zero byte
|
||||
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 end-of-line-translation
|
||||
@ -638,7 +638,7 @@ distribution).
|
||||
<para>
|
||||
If OIDs are included in the file, the OID field immediately follows the
|
||||
field-count word. It is a normal field except that it's not included
|
||||
in the field-count. In particular it has a length word --- this will allow
|
||||
in the field-count. In particular it has a length word — this will allow
|
||||
handling of 4-byte vs. 8-byte OIDs without too much pain, and will allow
|
||||
OIDs to be shown as null if that ever proves desirable.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.31 2004/06/17 12:41:02 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/declare.sgml,v 1.32 2004/11/15 06:32:15 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -78,7 +78,7 @@ DECLARE <replaceable class="parameter">name</replaceable> [ BINARY ] [ INSENSITI
|
||||
specifies whether data is to be retrieved in text or binary format.
|
||||
This choice overrides the way that the cursor is defined. The concept
|
||||
of a binary cursor as such is thus obsolete when using extended query
|
||||
protocol --- any cursor can be treated as either text or binary.
|
||||
protocol — any cursor can be treated as either text or binary.
|
||||
</para>
|
||||
</note>
|
||||
</refsect1>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.43 2004/10/01 16:39:47 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/lock.sgml,v 1.44 2004/11/15 06:32:15 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -71,7 +71,7 @@ where <replaceable class="PARAMETER">lockmode</replaceable> is one of:
|
||||
TABLE</> statement before executing any data modification
|
||||
statement. A serializable transaction's view of data will be
|
||||
frozen when its first data modification statement begins. A later
|
||||
<command>LOCK TABLE</> will still prevent concurrent writes --- but it
|
||||
<command>LOCK TABLE</> will still prevent concurrent writes — but it
|
||||
won't ensure that what the transaction reads corresponds to the
|
||||
latest committed values.
|
||||
</para>
|
||||
@ -85,7 +85,7 @@ where <replaceable class="PARAMETER">lockmode</replaceable> is one of:
|
||||
mode, and then be unable to also acquire <literal>ROW EXCLUSIVE</>
|
||||
mode to actually perform their updates. (Note that a transaction's
|
||||
own locks never conflict, so a transaction can acquire <literal>ROW
|
||||
EXCLUSIVE</> mode when it holds <literal>SHARE</> mode --- but not
|
||||
EXCLUSIVE</> mode when it holds <literal>SHARE</> mode — but not
|
||||
if anyone else holds <literal>SHARE</> mode.) To avoid deadlocks,
|
||||
make sure all transactions acquire locks on the same objects in the
|
||||
same order, and if multiple lock modes are involved for a single
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postgres-ref.sgml,v 1.44 2004/10/08 01:36:32 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/ref/postgres-ref.sgml,v 1.45 2004/11/15 06:32:15 neilc Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
@ -393,7 +393,7 @@ PostgreSQL documentation
|
||||
<literal>SIGQUIT</literal> to terminate without the normal cleanup.
|
||||
These signals <emphasis>should not</emphasis> be used by users. It is also
|
||||
unwise to send <literal>SIGKILL</literal> to a <command>postgres</command>
|
||||
process --- the <command>postmaster</command> will interpret this as
|
||||
process — the <command>postmaster</command> will interpret this as
|
||||
a crash in <command>postgres</command>, and will force all the sibling
|
||||
<command>postgres</command> processes to quit as part of its standard
|
||||
crash-recovery procedure.
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.41 2004/08/09 05:34:39 tgl Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/regress.sgml,v 1.42 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
@ -211,7 +211,7 @@ gmake installcheck
|
||||
fail if you run the test on the day of a daylight-saving time
|
||||
changeover, or the day after one. These queries expect that
|
||||
the intervals between midnight yesterday, midnight today and
|
||||
midnight tomorrow are exactly twenty-four hours --- which is wrong
|
||||
midnight tomorrow are exactly twenty-four hours — which is wrong
|
||||
if daylight-saving time went into or out of effect meanwhile.
|
||||
</para>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.35 2004/05/16 23:22:07 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/rules.sgml,v 1.36 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
|
||||
<Chapter Id="rules">
|
||||
<Title>The Rule System</Title>
|
||||
@ -546,7 +546,7 @@ SELECT shoelace.sl_name, shoelace.sl_avail,
|
||||
the remaining range-table entries in the top query (in this example there
|
||||
are no more), and it will recursively check the range-table entries in
|
||||
the added subquery to see if any of them reference views. (But it
|
||||
won't expand <literal>*OLD*</> or <literal>*NEW*</> --- otherwise we'd have infinite recursion!)
|
||||
won't expand <literal>*OLD*</> or <literal>*NEW*</> — otherwise we'd have infinite recursion!)
|
||||
In this example, there are no rewrite rules for <literal>shoelace_data</> or <literal>unit</>,
|
||||
so rewriting is complete and the above is the final result given to
|
||||
the planner.
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.14 2004/05/08 02:13:31 momjian Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sources.sgml,v 2.15 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="source">
|
||||
@ -117,7 +117,7 @@ less -x4
|
||||
error). The <function>errcode</> call specifies the SQLSTATE error code
|
||||
using a macro defined in <filename>src/include/utils/errcodes.h</>. The
|
||||
<function>errmsg</> call provides the primary message text. Notice the
|
||||
extra set of parentheses surrounding the auxiliary function calls ---
|
||||
extra set of parentheses surrounding the auxiliary function calls —
|
||||
these are annoying but syntactically necessary.
|
||||
</para>
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sql.sgml,v 1.32 2003/11/29 19:51:37 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/sql.sgml,v 1.33 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-intro">
|
||||
@ -1314,7 +1314,7 @@ SELECT COUNT(PNO)
|
||||
<para>
|
||||
<acronym>SQL</acronym> allows one to partition the tuples of a table
|
||||
into groups. Then the
|
||||
aggregate operators described above can be applied to the groups ---
|
||||
aggregate operators described above can be applied to the groups —
|
||||
i.e. the value of the aggregate operator is no longer calculated over
|
||||
all the values of the specified column but over all values of a
|
||||
group. Thus the aggregate operator is evaluated separately for every
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.96 2004/10/26 22:16:12 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/syntax.sgml,v 1.97 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<chapter id="sql-syntax">
|
||||
@ -725,9 +725,10 @@ SELECT 5 ! - 6;
|
||||
<programlisting>
|
||||
SELECT 5 ! (- 6);
|
||||
</programlisting>
|
||||
because the parser has no idea -- until it is too late -- that
|
||||
<token>!</token> is defined as a postfix operator, not an infix one.
|
||||
To get the desired behavior in this case, you must write
|
||||
because the parser has no idea — until it is too late
|
||||
— that <token>!</token> is defined as a postfix operator,
|
||||
not an infix one. To get the desired behavior in this case, you
|
||||
must write
|
||||
<programlisting>
|
||||
SELECT (5 !) - 6;
|
||||
</programlisting>
|
||||
@ -1259,7 +1260,7 @@ sqrt(2)
|
||||
The first form of aggregate expression invokes the aggregate
|
||||
across all input rows for which the given expression yields a
|
||||
non-null value. (Actually, it is up to the aggregate function
|
||||
whether to ignore null values or not --- but all the standard ones do.)
|
||||
whether to ignore null values or not — but all the standard ones do.)
|
||||
The second form is the same as the first, since
|
||||
<literal>ALL</literal> is the default. The third form invokes the
|
||||
aggregate for all distinct non-null values of the expression found
|
||||
@ -1546,7 +1547,7 @@ SELECT ROW(1,2.5,'this is a test');
|
||||
<para>
|
||||
By default, the value created by a <literal>ROW</> expression is of
|
||||
an anonymous record type. If necessary, it can be cast to a named
|
||||
composite type --- either the rowtype of a table, or a composite type
|
||||
composite type — either the rowtype of a table, or a composite type
|
||||
created with <command>CREATE TYPE AS</>. An explicit cast may be needed
|
||||
to avoid ambiguity. For example:
|
||||
<programlisting>
|
||||
|
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.30 2004/11/15 04:35:57 neilc Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.31 2004/11/15 06:32:14 neilc Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
||||
@ -87,7 +87,7 @@
|
||||
we simply install a prior physical backup of the database, and
|
||||
replay the WAL log just as far as the desired time. What's more,
|
||||
the physical backup doesn't have to be an instantaneous snapshot
|
||||
of the database state --- if it is made over some period of time,
|
||||
of the database state — if it is made over some period of time,
|
||||
then replaying the WAL log for that period will fix any internal
|
||||
inconsistencies.
|
||||
</para>
|
||||
@ -306,7 +306,7 @@
|
||||
<para>
|
||||
To deal with the case where <filename>pg_control</filename> is
|
||||
corrupted, we should support the possibility of scanning existing log
|
||||
segments in reverse order -- newest to oldest -- in order to find the
|
||||
segments in reverse order — newest to oldest — in order to find the
|
||||
latest checkpoint. This has not been implemented yet.
|
||||
<filename>pg_control</filename> is small enough (less than one disk page)
|
||||
that it is not subject to partial-write problems, and as of this writing
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.24 2003/11/29 19:51:38 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.25 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xaggr">
|
||||
@ -67,7 +67,7 @@ SELECT complex_sum(a) FROM test_complex;
|
||||
<para>
|
||||
The above definition of <function>sum</function> will return zero (the initial
|
||||
state condition) if there are no nonnull input values.
|
||||
Perhaps we want to return null in that case instead --- the SQL standard
|
||||
Perhaps we want to return null in that case instead — the SQL standard
|
||||
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>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.88 2004/09/20 22:48:25 tgl Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.89 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xfunc">
|
||||
@ -702,7 +702,7 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
|
||||
compiled into dynamically loadable objects (also called shared
|
||||
libraries) and are loaded by the server on demand. The dynamic
|
||||
loading feature is what distinguishes <quote>C language</> functions
|
||||
from <quote>internal</> functions --- the actual coding conventions
|
||||
from <quote>internal</> functions — the actual coding conventions
|
||||
are essentially the same for both. (Hence, the standard internal
|
||||
function library is a rich source of coding examples for user-defined
|
||||
C functions.)
|
||||
@ -1170,7 +1170,7 @@ memcpy(destination->data, buffer, 40);
|
||||
<title>Calling Conventions Version 0 for C-Language Functions</title>
|
||||
|
||||
<para>
|
||||
We present the <quote>old style</quote> calling convention first --- although
|
||||
We present the <quote>old style</quote> calling convention first — although
|
||||
this approach is now deprecated, it's easier to get a handle on
|
||||
initially. In the version-0 method, the arguments and result
|
||||
of the C function are just declared in normal C style, but being
|
||||
@ -1971,7 +1971,7 @@ AttInMetadata *TupleDescGetAttInMetadata(TupleDesc tupdesc)
|
||||
</programlisting>
|
||||
if you plan to work with C strings. If you are writing a function
|
||||
returning set, you can save the results of these functions in the
|
||||
<structname>FuncCallContext</> structure --- use the
|
||||
<structname>FuncCallContext</> structure — use the
|
||||
<structfield>tuple_desc</> or <structfield>attinmeta</> field
|
||||
respectively.
|
||||
</para>
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.36 2003/11/29 19:51:38 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.37 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xindex">
|
||||
@ -42,7 +42,7 @@ $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.36 2003/11/29 19:51:38 pgsql Exp
|
||||
<productname>PostgreSQL</productname>, but all index methods are
|
||||
described in <classname>pg_am</classname>. It is possible to add a
|
||||
new index method by defining the required interface routines and
|
||||
then creating a row in <classname>pg_am</classname> --- but that is
|
||||
then creating a row in <classname>pg_am</classname> — but that is
|
||||
far beyond the scope of this chapter.
|
||||
</para>
|
||||
|
||||
@ -745,7 +745,7 @@ SELECT * FROM table WHERE integer_column < 4;
|
||||
Consider again the situation where we are storing in the index only
|
||||
the bounding box of a complex object such as a polygon. In this
|
||||
case there's not much value in storing the whole polygon in the index
|
||||
entry --- we may as well store just a simpler object of type
|
||||
entry — we may as well store just a simpler object of type
|
||||
<type>box</>. This situation is expressed by the <literal>STORAGE</>
|
||||
option in <command>CREATE OPERATOR CLASS</>: we'd write something like
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.31 2003/11/29 19:51:38 pgsql Exp $
|
||||
$PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.32 2004/11/15 06:32:14 neilc Exp $
|
||||
-->
|
||||
|
||||
<sect1 id="xoper">
|
||||
@ -132,7 +132,7 @@ SELECT (a + b) AS c FROM test_complex;
|
||||
<literal>tab2.y = tab1.x</>, because the index-scan machinery expects
|
||||
to see the indexed column on the left of the operator it is given.
|
||||
<ProductName>PostgreSQL</ProductName> will <emphasis>not</> simply
|
||||
assume that this is a valid transformation --- the creator of the
|
||||
assume that this is a valid transformation — the creator of the
|
||||
<literal>=</> operator must specify that it is valid, by marking the
|
||||
operator with commutator information.
|
||||
</para>
|
||||
|
Loading…
Reference in New Issue
Block a user