Update interval documenation to mention the storage system used.

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 03732ba9cab06116f9f9fd6e3b366fb59bfc87c4..811033cb59ef9c3e68792b61499e6e0ab1f814b5 100644 (file)
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -1841,9 +1841,20 @@ January 8 04:05:06 1999 PST
      
 
      
-      The optional precision
-      p should be between 0 and 6, and
-      defaults to the precision of the input literal.
+      The optional subsecond precision p should 
+      be between 0 and 6, and defaults to the precision of the input literal.
+     
+
+     
+      Internally interval values are stored as months, days,
+      and seconds. This is done because the number of days in a month
+      varies, and a day can have 23 or 25 hours if a daylight savings
+      time adjustment is involved. Because intervals are usually created
+      from constant strings or timestamp subtraction, this
+      storage method works well in most cases. Functions
+      justify_days and justify_hours are
+      available for adjusting days and hours that overflow their normal
+      periods.
      
     
 
@@ -1936,7 +1947,7 @@ January 8 04:05:06 1999 PST
       CURRENT_DATE, CURRENT_TIME, 
       CURRENT_TIMESTAMP, LOCALTIME, 
       LOCALTIMESTAMP.  The latter four accept an 
-      optional precision specification.  (See 
+      optional subsecond precision specification.  (See 
       linkend="functions-datetime-current">.)  Note however that these are
       SQL functions and are not recognized as data input strings.