Add some documentation about handling of fractions in interval input.

(It's always worked like this, but we never documented it before.)

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 10da67ef5c61ea3dee95228b444abf6d87128517..d26fdc5fde61680e47a79cee3513c450fd301a22 100644 (file)
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1,4 +1,4 @@
-
+
 
  
   Data Types
@@ -2413,13 +2413,26 @@ January 8 04:05:06 1999 PST
      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
+     time adjustment is involved.  The months and days fields are integers
+     while the seconds field can store fractions.  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
      ranges.
     
+
+    
+     In the verbose input format, and in some fields of the more compact
+     input formats, field values can have fractional parts; for example
+     '1.5 week' or '01:02:03.45'.  Such input is
+     converted to the appropriate number of months, days, and seconds
+     for storage.  When this would result in a fractional number of
+     months or days, the fraction is added to the lower-order fields
+     using the conversion factors 1 month = 30 days and 1 day = 24 hours.
+     For example, '1.5 month' becomes 1 month and 15 days.
+     Only seconds will ever be shown as fractional on output.
+