Index: FAQ.html
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/FAQ/FAQ.html,v
retrieving revision 1.130
diff -u -r1.130 FAQ.html
--- FAQ.html	2002/04/18 04:45:11	1.130
+++ FAQ.html	2002/04/25 13:20:01
@@ -81,6 +81,8 @@
     clients"</I> when trying to connect?<BR>
      <A href="#3.9">3.9</A>) What are the <I>pg_sorttempNNN.NN</I>
     files in my database directory?<BR>
+     <A href="#3.10">3.10</A>) Why do I need to do a dump and restore 
+    to upgrade PostgreSQL?<BR>
      
 
     <H2 align="center">Operational Questions</H2>
@@ -788,6 +790,26 @@
     not if a backend crashes during a sort. If you have no backends
     running at the time, it is safe to delete the pg_tempNNN.NN
     files.</P>
+
+    <H4><A name="3.10">3.10</A>) Why do I need to do a dump and restore 
+    to upgrade PostgreSQL?</H4>
+
+    <P>The PostgreSQL team tries very heard to maintain compatability across
+    minor releases. So upgrading from 7.2 to 7.2.1 does not require a dump a
+    restore. However, new features are continuously being adding and
+    sometimes this requires new fields to be added to system tables.
+
+    <P>These changes may be across many tables and so maintaining backward
+    compatability would be quite difficult. Thus, restoring from a dump is
+    required to make everything work.
+
+    <P>Note that the actual on-disk file format does not change very often,
+    a feature the pg_upgrade script uses quite successfully. There the dump
+    is used create the necessary information in the system tables. The data
+    files are then just copied across. This method is not as guarenteed as
+    the dump/restore method but when it works it can make upgrades very
+    efficient.
+
     <HR>
 
     <H2 align="center">Operational Questions</H2>