Update documentation on may/can/might:

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

Also update two error messages mentioned in the documenation to match.

Author: bmomjian

doc/src/sgml/advanced.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.52 2006/10/21 23:12:57 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.53 2007/01/31 20:56:16 momjian Exp $ -->
 
  <chapter id="tutorial-advanced">
   <title>Advanced Features</title>
@@ -57,7 +57,7 @@ SELECT * FROM myview;
    <para>
     Making liberal use of views is a key aspect of good SQL database
     design.  Views allow you to encapsulate the details of the
-    structure of your tables, which may change as your application
+    structure of your tables, which might change as your application
     evolves, behind consistent interfaces.
    </para>
 
@@ -250,7 +250,7 @@ COMMIT;
    <note>
     <para>
      Some client libraries issue <command>BEGIN</> and <command>COMMIT</>
-     commands automatically, so that you may get the effect of transaction
+     commands automatically, so that you might get the effect of transaction
      blocks without asking.  Check the documentation for the interface
      you are using.
     </para>

doc/src/sgml/arch-dev.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.28 2006/09/16 00:30:11 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/arch-dev.sgml,v 2.29 2007/01/31 20:56:16 momjian Exp $ -->
 
  <chapter id="overview">
   <title>Overview of PostgreSQL Internals</title>
@@ -272,7 +272,7 @@
      similar to the raw parse tree in most places, but it has many differences
      in detail.  For example, a <structname>FuncCall</> node in the
      parse tree represents something that looks syntactically like a function
-     call.  This may be transformed to either a <structname>FuncExpr</>
+     call.  This might be transformed to either a <structname>FuncExpr</>
      or <structname>Aggref</> node depending on whether the referenced
      name turns out to be an ordinary function or an aggregate function.
      Also, information about the actual data types of columns and expression
@@ -342,7 +342,7 @@
    <note>
     <para>
      In some situations, examining each possible way in which a query
-     may be executed would take an excessive amount of time and memory
+     can be executed would take an excessive amount of time and memory
      space. In particular, this occurs when executing queries
      involving large numbers of join operations. In order to determine
      a reasonable (not optimal) query plan in a reasonable amount of
@@ -414,7 +414,7 @@
         scanned in parallel, and matching rows are combined to form
         join rows. This kind of join is more
         attractive because each relation has to be scanned only once.
-        The required sorting may be achieved either by an explicit sort
+        The required sorting might be achieved either by an explicit sort
         step, or by scanning the relation in the proper order using an
         index on the join key.
        </para>
@@ -502,7 +502,7 @@
    </para>
 
    <para>
-    Complex queries may involve many levels of plan nodes, but the general
+    Complex queries can involve many levels of plan nodes, but the general
     approach is the same: each node computes and returns its next output
     row each time it is called.  Each node is also responsible for applying
     any selection or projection expressions that were assigned to it by
@@ -518,7 +518,7 @@
     into the target table specified for the <command>INSERT</>.  (A simple
     <command>INSERT ... VALUES</> command creates a trivial plan tree
     consisting of a single <literal>Result</> node, which computes just one
-    result row.  But <command>INSERT ... SELECT</> may demand the full power
+    result row.  But <command>INSERT ... SELECT</> can demand the full power
     of the executor mechanism.)  For <command>UPDATE</>, the planner arranges
     that each computed row includes all the updated column values, plus
     the <firstterm>TID</> (tuple ID, or row ID) of the original target row;

doc/src/sgml/array.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.54 2007/01/31 04:12:01 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.55 2007/01/31 20:56:16 momjian Exp $ -->
 
 <sect1 id="arrays">
  <title>Arrays</title>
@@ -63,7 +63,7 @@ CREATE TABLE tictactoe (
  </para>
 
  <para>
-  An alternative syntax, which conforms to the SQL standard, may
+  An alternative syntax, which conforms to the SQL standard, can
   be used for one-dimensional arrays.
   <structfield>pay_by_quarter</structfield> could have been defined
   as:
@@ -88,7 +88,7 @@ CREATE TABLE tictactoe (
    To write an array value as a literal constant, enclose the element
    values within curly braces and separate them by commas.  (If you
    know C, this is not unlike the C syntax for initializing
-   structures.)  You may put double quotes around any element value,
+   structures.)  You can put double quotes around any element value,
    and must do so if it contains commas or curly braces.  (More
    details appear below.)  Thus, the general format of an array
    constant is the following:
@@ -155,7 +155,7 @@ SELECT * FROM sal_emp;
  </para>
 
  <para>
-  The <literal>ARRAY</> constructor syntax may also be used:
+  The <literal>ARRAY</> constructor syntax can also be used:
 <programlisting>
 INSERT INTO sal_emp
     VALUES ('Bill',
@@ -333,7 +333,7 @@ UPDATE sal_emp SET pay_by_quarter = ARRAY[25000,25000,27000,27000]
     WHERE name = 'Carol';
 </programlisting>
 
-  An array may also be updated at a single element:
+  An array can also be updated at a single element:
 
 <programlisting>
 UPDATE sal_emp SET pay_by_quarter[4] = 15000
@@ -453,7 +453,7 @@ SELECT array_dims(ARRAY[1,2] || ARRAY[[3,4],[5,6]]);
 
   Note that the concatenation operator discussed above is preferred over
   direct use of these functions. In fact, the functions exist primarily for use
-  in implementing the concatenation operator. However, they may be directly
+  in implementing the concatenation operator. However, they might be directly
   useful in the creation of user-defined aggregates. Some examples:
 
 <programlisting>
@@ -525,7 +525,7 @@ SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
  <tip>
   <para>
    Arrays are not sets; searching for specific array elements
-   may be a sign of database misdesign.  Consider
+   can be a sign of database misdesign.  Consider
    using a separate table with a row for each item that would be an
    array element.  This will be easier to search, and is likely to
    scale up better to large numbers of elements.
@@ -592,7 +592,7 @@ SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
    or backslashes disables this and allows the literal string value
    <quote>NULL</> to be entered.  Also, for backwards compatibility with
    pre-8.2 versions of <productname>PostgreSQL</>, the <xref
-   linkend="guc-array-nulls"> configuration parameter may be turned
+   linkend="guc-array-nulls"> configuration parameter might be turned
    <literal>off</> to suppress recognition of <literal>NULL</> as a NULL.
   </para>
 
@@ -611,8 +611,8 @@ SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2
   </para>
 
   <para>
-   You may write whitespace before a left brace or after a right
-   brace. You may also write whitespace before or after any individual item
+   You can write whitespace before a left brace or after a right
+   brace. You can also write whitespace before or after any individual item
    string. In all of these cases the whitespace will be ignored. However,
    whitespace within double-quoted elements, or surrounded on both sides by
    non-whitespace characters of an element, is not ignored.

doc/src/sgml/backup.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.95 2006/12/01 03:29:15 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.96 2007/01/31 20:56:16 momjian Exp $ -->
 
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -124,7 +124,7 @@ psql <replaceable class="parameter">dbname</replaceable> &lt; <replaceable class
 
    <para>
     By default, the <application>psql</> script will continue to
-    execute after an SQL error is encountered. You may wish to use the
+    execute after an SQL error is encountered. You might wish to use the
     following command at the top of the script to alter that
     behaviour and have <application>psql</application> exit with an
     exit status of 3 if an SQL error occurs:
@@ -138,7 +138,7 @@ psql <replaceable class="parameter">dbname</replaceable> &lt; <replaceable class
     passing the <option>-1</> or <option>--single-transaction</>
     command-line options to <application>psql</>. When using this
     mode, be aware that even the smallest of errors can rollback a
-    restore that has already run for many hours. However, that may
+    restore that has already run for many hours. However, that might
     still be preferable to manually cleaning up a complex database
     after a partially restored dump.
    </para>
@@ -325,7 +325,7 @@ tar -cf backup.tar /usr/local/pgsql/data
     <listitem>
      <para>
       If you have dug into the details of the file system layout of the
-      database, you may be tempted to try to back up or restore only certain
+      database, you might be tempted to try to back up or restore only certain
       individual tables or databases from their respective files or
       directories. This will <emphasis>not</> work because the
       information contained in these files contains only half the
@@ -360,7 +360,7 @@ tar -cf backup.tar /usr/local/pgsql/data
   </para>
 
   <para>
-   If your database is spread across multiple file systems, there may not 
+   If your database is spread across multiple file systems, there might not 
    be any way to obtain exactly-simultaneous frozen snapshots of all 
    the volumes.  For example, if your data files and WAL log are on different
    disks, or if tablespaces are on different file systems, it might
@@ -437,7 +437,7 @@ tar -cf backup.tar /usr/local/pgsql/data
      Since we can string together an indefinitely long sequence of WAL files
      for replay, continuous backup can be achieved simply by continuing to archive
      the WAL files.  This is particularly valuable for large databases, where
-     it may not be convenient to take a full backup frequently.
+     it might not be convenient to take a full backup frequently.
     </para>
    </listitem>
    <listitem>
@@ -465,7 +465,7 @@ tar -cf backup.tar /usr/local/pgsql/data
   <para>
    As with the plain file-system-backup technique, this method can only
    support restoration of an entire database cluster, not a subset.
-   Also, it requires a lot of archival storage: the base backup may be bulky,
+   Also, it requires a lot of archival storage: the base backup might be bulky,
    and a busy system will generate many megabytes of WAL traffic that
    have to be archived.  Still, it is the preferred backup technique in
    many situations where high reliability is needed.
@@ -534,7 +534,7 @@ archive_command = 'cp -i %p /mnt/server/archivedir/%f &lt;/dev/null'
 </programlisting>
     which will copy archivable WAL segments to the directory
     <filename>/mnt/server/archivedir</>.  (This is an example, not a 
-    recommendation, and may not work on all platforms.)
+    recommendation, and might not work on all platforms.)
    </para>
 
    <para>
@@ -601,7 +601,7 @@ archive_command = 'test ! -f .../%f &amp;&amp; cp %p .../%f'
 
    <para>
     In writing your archive command, you should assume that the file names to
-    be archived may be up to 64 characters long and may contain any
+    be archived can be up to 64 characters long and can contain any
     combination of ASCII letters, digits, and dots.  It is not necessary to
     remember the original relative path (<literal>%p</>) but it is necessary to
     remember the file name (<literal>%f</>).
@@ -614,7 +614,7 @@ archive_command = 'test ! -f .../%f &amp;&amp; cp %p .../%f'
     <filename>postgresql.conf</>, <filename>pg_hba.conf</> and
     <filename>pg_ident.conf</>), since those are edited manually rather
     than through SQL operations.
-    You may wish to keep the configuration files in a location that will
+    You might wish to keep the configuration files in a location that will
     be backed up by your regular file system backup procedures.  See
     <xref linkend="runtime-config-file-locations"> for how to relocate the
     configuration files.
@@ -732,7 +732,7 @@ SELECT pg_stop_backup();
     between <function>pg_start_backup</> and the start of the actual backup,
     nor between the end of the backup and <function>pg_stop_backup</>; a
     few minutes' delay won't hurt anything.  (However, if you normally run the
-    server with <varname>full_page_writes</> disabled, you may notice a drop
+    server with <varname>full_page_writes</> disabled, you might notice a drop
     in performance between <function>pg_start_backup</> and 
     <function>pg_stop_backup</>, since <varname>full_page_writes</> is
     effectively forced on during backup mode.)  You must ensure that these
@@ -750,7 +750,7 @@ SELECT pg_stop_backup();
    </para>
 
    <para>
-    You may, however, omit from the backup dump the files within the
+    You can, however, omit from the backup dump the files within the
     <filename>pg_xlog/</> subdirectory of the cluster directory.  This
     slight complication is worthwhile because it reduces the risk
     of mistakes when restoring.  This is easy to arrange if
@@ -775,7 +775,7 @@ SELECT pg_stop_backup();
     the file system backup and the WAL segment files used during the
     backup (as specified in the backup history file), all archived WAL
     segments with names numerically less are no longer needed to recover
-    the file system backup and may be deleted. However, you should
+    the file system backup and can be deleted. However, you should
     consider keeping several backup sets to be absolutely certain that
     you can recover your data.
    </para>
@@ -842,7 +842,7 @@ SELECT pg_stop_backup();
      require that you have enough free space on your system to hold two
      copies of your existing database. If you do not have enough space, 
      you need at the least to copy the contents of the <filename>pg_xlog</>
-     subdirectory of the cluster data directory, as it may contain logs which
+     subdirectory of the cluster data directory, as it might contain logs which
      were not archived before the system went down.
     </para>
    </listitem>
@@ -881,7 +881,7 @@ SELECT pg_stop_backup();
    <listitem>
     <para>
      Create a recovery command file <filename>recovery.conf</> in the cluster
-     data directory (see <xref linkend="recovery-config-settings">). You may 
+     data directory (see <xref linkend="recovery-config-settings">). You might
      also want to temporarily modify <filename>pg_hba.conf</> to prevent 
      ordinary users from connecting until you are sure the recovery has worked.
     </para>
@@ -917,7 +917,7 @@ SELECT pg_stop_backup();
     <filename>recovery.conf</> is the <varname>restore_command</>,
     which tells <productname>PostgreSQL</> how to get back archived
     WAL file segments.  Like the <varname>archive_command</>, this is
-    a shell command string.  It may contain <literal>%f</>, which is
+    a shell command string.  It can contain <literal>%f</>, which is
     replaced by the name of the desired log file, and <literal>%p</>,
     which is replaced by the path name to copy the log file to.
     (The path name is relative to the working directory of the server,
@@ -1228,8 +1228,8 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
     It should also be noted that the default <acronym>WAL</acronym>
     format is fairly bulky since it includes many disk page snapshots.
     These page snapshots are designed to support crash recovery, since
-    we may need to fix partially-written disk pages.  Depending on
-    your system hardware and software, the risk of partial writes may
+    we might need to fix partially-written disk pages.  Depending on
+    your system hardware and software, the risk of partial writes might
     be small enough to ignore, in which case you can significantly
     reduce the total volume of archived logs by turning off page
     snapshots using the <xref linkend="guc-full-page-writes">
@@ -1238,7 +1238,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
     use of the logs for PITR operations.  An area for future
     development is to compress archived WAL data by removing
     unnecessary page copies even when <varname>full_page_writes</> is
-    on.  In the meantime, administrators may wish to reduce the number
+    on.  In the meantime, administrators might wish to reduce the number
     of page snapshots included in WAL by increasing the checkpoint
     interval parameters as much as feasible.
    </para>
@@ -1522,15 +1522,15 @@ if (!triggered)
     connectivity between the two and the viability of the primary. It is
     also possible to use a third system (called a witness server) to avoid
     some problems of inappropriate failover, but the additional complexity
-    may not be worthwhile unless it is set-up with sufficient care and
+    might not be worthwhile unless it is set-up with sufficient care and
     rigorous testing.
    </para>
 
    <para>
     Once failover to the standby occurs, we have only a
     single server in operation. This is known as a degenerate state.
     The former standby is now the primary, but the former primary is down 
-    and may stay down.  To return to normal operation we must
+    and might stay down.  To return to normal operation we must
     fully recreate a standby server, 
     either on the former primary system when it comes up, or on a third, 
     possibly new, system. Once complete the primary and standby can be 
@@ -1662,7 +1662,7 @@ if (!triggered)
    It is recommended that you use the <application>pg_dump</> and
    <application>pg_dumpall</> programs from the newer version of
    <productname>PostgreSQL</>, to take advantage of any enhancements
-   that may have been made in these programs.  Current releases of the
+   that might have been made in these programs.  Current releases of the
    dump programs can read data from any server version back to 7.0.
   </para>
 
@@ -1716,7 +1716,7 @@ psql -f backup postgres
   <note>
    <para>
     When you <quote>move the old installation out of the way</quote>
-    it may no longer be perfectly usable. Some of the executable programs
+    it might no longer be perfectly usable. Some of the executable programs
     contain absolute paths to various installed programs and data files.
     This is usually not a big problem but if you plan on using two
     installations in parallel for a while you should assign them

doc/src/sgml/bki.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.19 2006/09/16 00:30:11 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/bki.sgml,v 1.20 2007/01/31 20:56:16 momjian Exp $ -->
 
 <chapter id="bki">
  <title><acronym>BKI</acronym> Backend Interface</title>
@@ -29,7 +29,7 @@
  </para>
 
  <para>
-  Related information may be found in the documentation for
+  Related information can be found in the documentation for
   <application>initdb</application>.
  </para>