This patch replaces "---" with "—" in the documentation, which is
the proper SGML character entity for an emdash.
Barring any objections, I'll apply this to HEAD before the end of the
day.
-Neil
# Old manifest: 01f0baf61d31b0bbe7563ce51fd262481b20ca57
# New manifest: fcb6532423fefa04824a2aefd07c4c9d7fe640b0
# Summary of changes:
#
# patch doc/src/sgml/array.sgml
# from 1b00c69d094632ee14178f62930153152a3b2a94
# to 8052e2bef3e4d6de12fee8706e9a7222830882ff
#
# patch doc/src/sgml/backup.sgml
# from 9af3e51f96d332e564060493443e172f1f5c9b5f
# to 40aa68c313f097cdbfa630864b86ee1a65fa65ae
#
# patch doc/src/sgml/catalogs.sgml
# from 66daa1980d14077db9fef757878cc7f1ea9e6644
# to 2a3562616974b84d37760722f88b70fec61a3de2
#
# patch doc/src/sgml/datetime.sgml
# from 83ba94e01004142ff3d45998136e288848dad8a9
# to f45c54ece8d562197f9cdae6d90c8d2e7e41e63a
#
# patch doc/src/sgml/ddl.sgml
# from e96d2b97e6c97dbdbe1ff717839aa615efd8aede
# to f29c9ba31362b3d5b84751266033742cc38cfa99
#
# patch doc/src/sgml/dfunc.sgml
# from b171f77de7b0131997837f55c9b8d6be310e6075
# to ad63f7cc25881541fc844617244df16725cf55a9
#
# patch doc/src/sgml/errcodes.sgml
# from c068effaebafa7e86a8ef1ba81bb9e4d725ae379
# to db00797ad0503ceb386a32fe2c1393ac9f86a234
#
# patch doc/src/sgml/func.sgml
# from 928b2aec84c396c5282bf8138fe9a3accdbc981f
# to 4e1580d4a478afd8c9a70df19940f387b989f09d
#
# patch doc/src/sgml/information_schema.sgml
# from dd030182cb6072a4554c451087c99281ea5adb4b
# to 890d3c6b5142e9f30cf87a837e317430e6ad8b3a
#
# patch doc/src/sgml/libpq.sgml
# from 038396930b6d0ce26a9bdd546421b1825e2d0228
# to 3bc6b064872ef91d95302029dd44a107c95c7f8e
#
# patch doc/src/sgml/maintenance.sgml
# from aadb76dd1db108dd83304cbad49f6d7c35da8133
# to 5fe574c7e81cdfc8bff67a30c94f6ceffe44ec5f
#
# patch doc/src/sgml/mvcc.sgml
# from 7159f3aad786afa521484da9fb789f9a11c8af61
# to 68951a11d2c7051dc2008ae40c543085e1012a90
#
# patch doc/src/sgml/perform.sgml
# from 3f5b510224a48f2d56bc7fd6ae809eec171438e2
# to 9f330a1a92bab64932253b7d5f14edadae523386
#
# patch doc/src/sgml/plpgsql.sgml
# from cf091d56e4b1c9554030d61099592b52e935d138
# to 08940a5da76b559f3a66136ab4523486481f08a1
#
# patch doc/src/sgml/protocol.sgml
# from 148daace598d221b4fb1de5ed596c788993c3266
# to bf8f3b8c0d4cf23aeba65dadfe70a2750487e2f0
#
# patch doc/src/sgml/queries.sgml
# from 4418fed2dbdb2c5621812bb3915ace53fb67dd66
# to fdd6f5d0a734e008276a12fb3a6a970b4f3febaf
#
# patch doc/src/sgml/query.sgml
# from 3f6f4c6699fc8dd029ab5a7d27ad4e864d2cc406
# to 288c88918d3587f565d710a84c49885c35efabbc
#
# patch doc/src/sgml/ref/cluster.sgml
# from acfd092cabdfc6f19ac901df0bc83ab551373d39
# to f6cfc959fcd35060bac1e3f6e6ae921204dc21e1
#
# patch doc/src/sgml/ref/copy.sgml
# from 661348d43626b2871e203d74fa7f976acc346287
# to 9fdc148930163d22540651fcfd0b07d4182f0158
#
# patch doc/src/sgml/ref/declare.sgml
# from 9961dae87ac389f5fe7593f664c15af5c76ed6b2
# to 689d73682b68411555b52f523191f2e45f9da7d7
#
# patch doc/src/sgml/ref/lock.sgml
# from e3dd1be0b6efde957b6a8f992377ff8da559c632
# to f0fbc57e3014961a6337ed2542cdd15ea6e749f0
#
# patch doc/src/sgml/ref/postgres-ref.sgml
# from e9388954ebb8d59144cee0bdd06d5d05f75a7007
# to d3010c3f04e96336e1bdc956b179bd7896b52785
#
# patch doc/src/sgml/regress.sgml
# from 86a51990076a31765b7275e05ba8f14bffc88464
# to b4ce3c46efb0c5b640ab3f1309b8cac9f9512dd1
#
# patch doc/src/sgml/rules.sgml
# from cf9e537241a6ee657e9ec461cad9bc6d512d1fb4
# to 136e5abe5960fd65b98901066f4cd9f1b68329c2
#
# patch doc/src/sgml/sources.sgml
# from f8d57c8d127dde3ab613d2c985f553befa05d3a4
# to d2bcbecbf2466dc9236b65310175c2c4b5baa104
#
# patch doc/src/sgml/sql.sgml
# from bf7cdc3dd1e8b057afa7d1688ad7b13e42e45953
# to 08953c131981ce3abc80c0028e11d0e1fe90d47a
#
# patch doc/src/sgml/syntax.sgml
# from d9b5fe8f14229b801db59c7d138c19af0afcba1f
# to 7f93fd4211e1f8cdffb42e0ff28954e1924e3129
#
# patch doc/src/sgml/wal.sgml
# from 9aa672dfa9ed46c1330677d16cbd985b1e5cbaa9
# to 30921a612739486af99e373e667ce7b1b882eb40
#
# patch doc/src/sgml/xaggr.sgml
# from 91d56faa5dddf742a1bfc79a49a87d7a495a28c4
# to e4c9732bf66e692185f9362a71b1737f97b77d5a
#
# patch doc/src/sgml/xfunc.sgml
# from b73db6406df8b3d0196a9019753ac8596b8742f8
# to e19cfec736613f3abc13362355e6a3a607a288a3
#
# patch doc/src/sgml/xindex.sgml
# from 990371873d8aad33013647888af8add8b71bf5f9
# to dbcf718a136c57fc75d6921137562cb2bfbf9248
#
# patch doc/src/sgml/xoper.sgml
# from 063c6801cb4078757dccee5f799bce757e2dd12e
# to e8f294f2be0d2c4f9f529aee7247471755c46897
#
--- doc/src/sgml/array.sgml
+++ doc/src/sgml/array.sgml
@@ -49,7 +49,7 @@
</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>
--- doc/src/sgml/backup.sgml
+++ doc/src/sgml/backup.sgml
@@ -499,7 +499,7 @@
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 @@
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>
--- doc/src/sgml/catalogs.sgml
+++ doc/src/sgml/catalogs.sgml
@@ -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>
--- doc/src/sgml/datetime.sgml
+++ doc/src/sgml/datetime.sgml
@@ -370,7 +370,7 @@
<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.)
--- doc/src/sgml/ddl.sgml
+++ doc/src/sgml/ddl.sgml
@@ -350,7 +350,7 @@
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>
--- doc/src/sgml/dfunc.sgml
+++ doc/src/sgml/dfunc.sgml
@@ -38,7 +38,7 @@
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
+ distinguish it from linking an executable. — At least this is the
theory. On some systems the practice is much uglier.
</para>
--- doc/src/sgml/errcodes.sgml
+++ doc/src/sgml/errcodes.sgml
@@ -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>
--- doc/src/sgml/func.sgml
+++ doc/src/sgml/func.sgml
@@ -2793,7 +2793,7 @@
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 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">
--- doc/src/sgml/information_schema.sgml
+++ doc/src/sgml/information_schema.sgml
@@ -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,
--- doc/src/sgml/libpq.sgml
+++ doc/src/sgml/libpq.sgml
@@ -2252,7 +2252,7 @@
<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.
--- doc/src/sgml/maintenance.sgml
+++ doc/src/sgml/maintenance.sgml
@@ -117,7 +117,7 @@
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 @@
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 @@
(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 @@
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>
--- doc/src/sgml/mvcc.sgml
+++ doc/src/sgml/mvcc.sgml
@@ -410,7 +410,7 @@
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 @@
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 @@
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
--- doc/src/sgml/perform.sgml
+++ doc/src/sgml/perform.sgml
@@ -576,7 +576,7 @@
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>
--- doc/src/sgml/plpgsql.sgml
+++ doc/src/sgml/plpgsql.sgml
@@ -129,7 +129,7 @@
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 @@
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 @@
<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>
--- doc/src/sgml/protocol.sgml
+++ doc/src/sgml/protocol.sgml
@@ -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
--- doc/src/sgml/queries.sgml
+++ doc/src/sgml/queries.sgml
@@ -135,7 +135,7 @@
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">
--- doc/src/sgml/query.sgml
+++ doc/src/sgml/query.sgml
@@ -37,7 +37,7 @@
</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:
--- doc/src/sgml/ref/cluster.sgml
+++ doc/src/sgml/ref/cluster.sgml
@@ -159,7 +159,7 @@
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>
--- doc/src/sgml/ref/copy.sgml
+++ doc/src/sgml/ref/copy.sgml
@@ -538,7 +538,7 @@
<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 @@
<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>
--- doc/src/sgml/ref/declare.sgml
+++ doc/src/sgml/ref/declare.sgml
@@ -78,7 +78,7 @@
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>
--- doc/src/sgml/ref/lock.sgml
+++ doc/src/sgml/ref/lock.sgml
@@ -71,7 +71,7 @@
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 @@
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
--- doc/src/sgml/ref/postgres-ref.sgml
+++ doc/src/sgml/ref/postgres-ref.sgml
@@ -393,7 +393,7 @@
<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.
--- doc/src/sgml/regress.sgml
+++ doc/src/sgml/regress.sgml
@@ -211,7 +211,7 @@
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>
--- doc/src/sgml/rules.sgml
+++ doc/src/sgml/rules.sgml
@@ -546,7 +546,7 @@
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.
--- doc/src/sgml/sources.sgml
+++ doc/src/sgml/sources.sgml
@@ -117,7 +117,7 @@
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>
--- doc/src/sgml/sql.sgml
+++ doc/src/sgml/sql.sgml
@@ -1314,7 +1314,7 @@
<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
--- doc/src/sgml/syntax.sgml
+++ doc/src/sgml/syntax.sgml
@@ -1259,7 +1259,7 @@
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 +1546,7 @@
<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>
--- doc/src/sgml/wal.sgml
+++ doc/src/sgml/wal.sgml
@@ -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>
--- doc/src/sgml/xaggr.sgml
+++ doc/src/sgml/xaggr.sgml
@@ -67,7 +67,7 @@
<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>
--- doc/src/sgml/xfunc.sgml
+++ doc/src/sgml/xfunc.sgml
@@ -702,7 +702,7 @@
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 @@
<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 @@
</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>
--- doc/src/sgml/xindex.sgml
+++ doc/src/sgml/xindex.sgml
@@ -42,7 +42,7 @@
<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 @@
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
--- doc/src/sgml/xoper.sgml
+++ doc/src/sgml/xoper.sgml
@@ -132,7 +132,7 @@
<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>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
