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.

1 files changed, 3 insertions, 3 deletions

diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index f5929e4f79..94a3deed6f 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/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>