Enable 64-bit integer datetimes by default, per previous discussion.

Neil Conway · Neil Conway · commit 2169e42bef9d · 2008-03-30T04:08:15.000Z
This requires a working 64-bit integer type. If such a type cannot
be found, "--disable-integer-datetimes" can be used to switch
back to the previous floating point-based datetime implementation.
diff --git a/configure b/configure
@@ -1349,7 +1349,7 @@ if test -n "$ac_init_help"; then
 Optional Features:
   --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
-  --enable-integer-datetimes  enable 64-bit integer date/time support
+  --disable-integer-datetimes  disable 64-bit integer date/time support
   --enable-nls[=LANGUAGES]  enable Native Language Support
   --disable-shared        do not build shared libraries
   --disable-rpath         do not embed shared library search path in executables
@@ -2176,7 +2176,7 @@ fi
 
 
 #
-# 64-bit integer date/time storage (--enable-integer-datetimes)
+# 64-bit integer date/time storage: enabled by default.
 #
 { echo "$as_me:$LINENO: checking whether to build with 64-bit integer date/time support" >&5
 echo $ECHO_N "checking whether to build with 64-bit integer date/time support... $ECHO_C" >&6; }
@@ -2205,7 +2205,11 @@ echo "$as_me: error: no argument expected for --enable-integer-datetimes option"
   esac
 
 else
-  enable_integer_datetimes=no
+  enable_integer_datetimes=yes
+
+cat >>confdefs.h <<\_ACEOF
+#define USE_INTEGER_DATETIMES 1
+_ACEOF
 
 fi
 
@@ -23293,6 +23297,26 @@ fi
 
 
 
+# If the user did not disable integer datetimes, check that
+# there is a working 64-bit integral type to use.
+if test x"$USE_INTEGER_DATETIMES" = x"yes" &&
+   test x"$HAVE_LONG_INT_64" = x"no" &&
+   test x"$HAVE_LONG_LONG_INT_64" = x"no" &&
+   test x"$HAVE_INT64" = x"no" ; then
+  { { echo "$as_me:$LINENO: error:
+Integer-based datetime support requires a 64-bit integer type,
+but no such type could be found. The --disable-integer-datetimes
+configure option can be used to disable integer-based storage
+of datetime values." >&5
+echo "$as_me: error:
+Integer-based datetime support requires a 64-bit integer type,
+but no such type could be found. The --disable-integer-datetimes
+configure option can be used to disable integer-based storage
+of datetime values." >&2;}
+   { (exit 1); exit 1; }; }
+fi
+
+
 if test "$PORTNAME" != "win32"
 then
 { echo "$as_me:$LINENO: checking for POSIX signal interface" >&5
diff --git a/configure.in b/configure.in
@@ -1,5 +1,5 @@
 dnl Process this file with autoconf to produce a configure script.
-dnl $PostgreSQL: pgsql/configure.in,v 1.554 2008/03/10 21:50:16 tgl Exp $
+dnl $PostgreSQL: pgsql/configure.in,v 1.555 2008/03/30 04:08:14 neilc Exp $
 dnl
 dnl Developers, please strive to achieve this order:
 dnl
@@ -128,10 +128,10 @@ PGAC_ARG_REQ(with, libs,      [  --with-libs=DIRS        alternative spelling of
 
 
 #
-# 64-bit integer date/time storage (--enable-integer-datetimes)
+# 64-bit integer date/time storage: enabled by default.
 #
 AC_MSG_CHECKING([whether to build with 64-bit integer date/time support])
-PGAC_ARG_BOOL(enable, integer-datetimes, no, [  --enable-integer-datetimes  enable 64-bit integer date/time support],
+PGAC_ARG_BOOL(enable, integer-datetimes, yes, [  --disable-integer-datetimes  disable 64-bit integer date/time support],
               [AC_DEFINE([USE_INTEGER_DATETIMES], 1,
                          [Define to 1 if you want 64-bit integer timestamp and interval support. (--enable-integer-datetimes)])])
 AC_MSG_RESULT([$enable_integer_datetimes])
@@ -1405,6 +1405,20 @@ AC_CHECK_TYPES([int8, uint8, int64, uint64], [], [],
 AC_CHECK_TYPES(sig_atomic_t, [], [], [#include <signal.h>])
 
 
+# If the user did not disable integer datetimes, check that
+# there is a working 64-bit integral type to use.
+if test x"$USE_INTEGER_DATETIMES" = x"yes" &&
+   test x"$HAVE_LONG_INT_64" = x"no" &&
+   test x"$HAVE_LONG_LONG_INT_64" = x"no" &&
+   test x"$HAVE_INT64" = x"no" ; then
+  AC_MSG_ERROR([
+Integer-based datetime support requires a 64-bit integer type,
+but no such type could be found. The --disable-integer-datetimes
+configure option can be used to disable integer-based storage
+of datetime values.])
+fi
+
+
 if test "$PORTNAME" != "win32"
 then
 PGAC_FUNC_POSIX_SIGNALS
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.173 2008/03/11 16:59:00 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.174 2008/03/30 04:08:14 neilc Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -4740,11 +4740,11 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       </indexterm>
       <listitem>
        <para>
-        Reports whether <productname>PostgreSQL</productname> was built
-        with support for 64-bit-integer dates and times.  It is set by
-        configuring with <literal>--enable-integer-datetimes</literal>
-        when building <productname>PostgreSQL</productname>.  The
-        default value is <literal>off</literal>.
+        Reports whether <productname>PostgreSQL</> was built with
+        support for 64-bit-integer dates and times.  This can be
+        disabled by configuring with <literal>--disable-integer-datetimes</>
+        when building <productname>PostgreSQL</>.  The default value is
+        <literal>on</literal>.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.225 2008/02/16 21:51:04 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.226 2008/03/30 04:08:14 neilc Exp $ -->
 
  <chapter id="datatype">
   <title id="datatype-title">Data Types</title>
@@ -1408,15 +1408,15 @@ SELECT b, char_length(b) FROM test2;
         <entry>8 bytes</entry>
         <entry>both date and time</entry>
         <entry>4713 BC</entry>
-        <entry>5874897 AD</entry>
+        <entry>294276 AD</entry>
         <entry>1 microsecond / 14 digits</entry>
        </row>
        <row>
         <entry><type>timestamp [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
         <entry>8 bytes</entry>
         <entry>both date and time, with time zone</entry>
         <entry>4713 BC</entry>
-        <entry>5874897 AD</entry>
+        <entry>294276 AD</entry>
         <entry>1 microsecond / 14 digits</entry>
        </row>
        <row>
@@ -1475,20 +1475,27 @@ SELECT b, char_length(b) FROM test2;
 
    <note>
    <para>
-    When <type>timestamp</> values are stored as double precision floating-point
-    numbers (currently the default), the effective limit of precision
-    might be less than 6. <type>timestamp</type> values are stored as seconds
-    before or after midnight 2000-01-01.  Microsecond precision is achieved for
-    dates within a few years of 2000-01-01, but the precision degrades for
-    dates further away.  When <type>timestamp</type> values are stored as
-    eight-byte integers (a compile-time
-    option), microsecond precision is available over the full range of
-    values. However eight-byte integer timestamps have a more limited range of
-    dates than shown above: from 4713 BC up to 294276 AD.  The same
-    compile-time option also determines whether <type>time</type> and
-    <type>interval</type> values are stored as floating-point or eight-byte
-    integers.  In the floating-point case, large <type>interval</type> values
-    degrade in precision as the size of the interval increases.
+    When <type>timestamp</> values are stored as eight-byte integers
+    (currently the default), microsecond precision is available over
+    the full range of values. When <type>timestamp</> values are
+    stored as double precision floating-point numbers instead (a
+    deprecated compile-time option), the effective limit of precision
+    might be less than 6. <type>timestamp</type> values are stored as
+    seconds before or after midnight 2000-01-01.  When
+    <type>timestamp</type> values are implemented using floating-point
+    numbers, microsecond precision is achieved for dates within a few
+    years of 2000-01-01, but the precision degrades for dates further
+    away. Note that using floating-point datetimes allows a larger
+    range of <type>timestamp</type> values to be represented than
+    shown above: from 4713 BC up to 5874897 AD.
+   </para>
+
+   <para>
+    The same compile-time option also determines whether
+    <type>time</type> and <type>interval</type> values are stored as
+    floating-point numbers or eight-byte integers.  In the
+    floating-point case, large <type>interval</type> values degrade in
+    precision as the size of the interval increases.
    </para>
    </note>
 
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.305 2008/03/25 22:50:27 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.306 2008/03/30 04:08:15 neilc Exp $ -->
 
 <chapter id="installation">
  <title><![%standalone-include[<productname>PostgreSQL</>]]>
@@ -1011,16 +1011,23 @@ su - postgres
       </varlistentry>
 
       <varlistentry>
-       <term><option>--enable-integer-datetimes</option></term>
+       <term><option>--disable-integer-datetimes</option></term>
        <listitem>
         <para>
-         Use 64-bit integer storage for datetimes and intervals, rather
-         than the default floating-point storage.  This reduces the range
-         of representable values but guarantees microsecond precision across
-         the full range (see
+         Disable support for 64-bit integer storage for timestamps and
+         intervals, and store datetime values as floating-point
+         numbers instead. Floating-point datetime storage was the
+         default in <productname>PostgreSQL</productname> releases
+         prior to 8.4, but it is now deprecated, because it does not
+         support microsecond precision for the full range of
+         <type>timestamp</type> values. However, integer-based
+         datetime storage requires a 64-bit integer type. Therefore,
+         this option can be used when no such type is available, or
+         for compatibility with applications written for prior
+         versions of <productname>PostgreSQL</productname>. See
          <![%standalone-include[the documentation about datetime datatypes]]>
          <![%standalone-ignore[<xref linkend="datatype-datetime">]]>
-         for more information).
+         for more information.
         </para>
        </listitem>
       </varlistentry>
