Replace "--" and "---" with "—" as appropriate, for better-looking

output.

doc/src/sgml/advanced.sgml

 <!--
-$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 &mdash;
     <command>SELECT</command>, <command>UPDATE</command>, and
-    <command>DELETE</command> -- support this <literal>ONLY</literal>
+    <command>DELETE</command> &mdash; support this <literal>ONLY</literal>
     notation.
    </para>
 

doc/src/sgml/array.sgml

-<!-- $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 &mdash; the behavior is the same as for arrays of unspecified
   length.
  </para>
 

doc/src/sgml/backup.sgml

 <!--
-$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 &mdash; 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 &mdash; 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

 <!--
  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 &mdash; 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 &mdash; 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
+   &mdash; at the cost that its schema must be extended whenever new slot types
    are defined for <structname>pg_statistic</structname>.
   </para>
 

doc/src/sgml/charset.sgml

-<!-- $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
+     &mdash; 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> &mdash; it is transformed to its
+     hexadecimal byte values in parentheses, e.g.,
+     <literal>(826C)</literal>.
     </para>
    </sect2>
 

doc/src/sgml/client-auth.sgml

 <!--
-$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 &mdash; see
   <xref linkend="user-manag"> for more information. Therefore, it is
   essential to restrict which database users can connect.
  </para>

doc/src/sgml/datetime.sgml

 <!--
-$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 &mdash; 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

-<!-- $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 &mdash; note that the limit is on number of
     <acronym>SQL</acronym> commands, not number of rows processed.
    </para>
  </sect1>

doc/src/sgml/dfunc.sgml

 <!--
-$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
+  &mdash; on some systems the practice is much uglier).
  </para>
 
  <para>

doc/src/sgml/docguide.sgml

-<!-- $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.
+       &mdash; do not use that.
       </para>
      </listitem>
     </varlistentry>

doc/src/sgml/errcodes.sgml

-<!-- $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 &mdash; this is also a warning class per SQL99</entry>
 </row>
 
 <row>

doc/src/sgml/func.sgml

 <!--
-$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 &mdash; 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 &mdash; if the name can be recognized at all, it must be visible.
    </para>
 
    <indexterm zone="functions-info">

doc/src/sgml/information_schema.sgml

-<!-- $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 &mdash; 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

 <!--
-$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 &mdash; 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

 <!--
-$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 &mdash; 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</> &mdash; 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 &mdash; 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 &mdash; 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

 <!--
-$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 &mdash; 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 &mdash; 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 &mdash; 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/nls.sgml

 <!--
-$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 &mdash; 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 &mdash; 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 &mdash; initially empty.
         </para>
        </listitem>
       </varlistentry>

doc/src/sgml/perform.sgml

 <!--
-$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
+   &mdash; assuming that you know of a better order, that is.  Experimentation
    is recommended.
   </para>
 

doc/src/sgml/plpgsql.sgml

 <!--
-$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 &mdash; 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 &mdash; 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</> &mdash;
         trigger arguments are passed via <varname>TG_ARGV</>, as described
         below.
   </para>

doc/src/sgml/protocol.sgml

-<!-- $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 &mdash; 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 &mdash; 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 &mdash; 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

-<!-- $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.
+    &mdash; 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 &mdash; 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;

doc/src/sgml/query.sgml

 <!--
-$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 &mdash; 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 &mdash; you choose.)
    </para>
 
    <para>

doc/src/sgml/ref/cluster.sgml

 <!--
-$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 &mdash; all such items must be
     manually recreated.
    </para>
  </refsect1>

doc/src/sgml/ref/copy.sgml

 <!--
-$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</> &mdash; 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 &mdash; 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

 <!--
-$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 &mdash; any cursor can be treated as either text or binary.
    </para>
   </note>
  </refsect1>

doc/src/sgml/ref/lock.sgml

 <!--
-$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 &mdash; 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 &mdash; 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

 <!--
-$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 &mdash; 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

-<!-- $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 &mdash; which is wrong
      if daylight-saving time went into or out of effect meanwhile.
     </para>
 

doc/src/sgml/rules.sgml

-<!-- $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*</> &mdash; 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

 <!--
-$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 &mdash;
     these are annoying but syntactically necessary.
    </para>
 

doc/src/sgml/sql.sgml

 <!--
-$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 &mdash;
       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

 <!--
-$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 &mdash; until it is too late
+    &mdash; 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 &mdash; 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 &mdash; 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

-<!-- $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 &mdash; 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 &mdash; newest to oldest &mdash; 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

doc/src/sgml/xaggr.sgml

 <!--
-$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 &mdash; 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

 <!--
-$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 &mdash; 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-&gt;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 &mdash; 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 &mdash; use the
      <structfield>tuple_desc</> or <structfield>attinmeta</> field
      respectively.
     </para>

doc/src/sgml/xindex.sgml

 <!--
-$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> &mdash; but that is
    far beyond the scope of this chapter.
   </para>
 
@@ -745,7 +745,7 @@ SELECT * FROM table WHERE integer_column &lt; 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 &mdash; 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

 <!--
-$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 &mdash; the creator of the
      <literal>=</> operator must specify that it is valid, by marking the
      operator with commutator information.
     </para>