database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

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

Browse Source 
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.
This commit is contained in:
Neil Conway
2008-03-30 04:08:15 +00:00
parent 2f6e61b8a6
commit 2169e42bef
5 changed files with 88 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/config.sgml
View File

@ -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>

41
doc/src/sgml/datatype.sgml
View File

@ -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,7 +1408,7 @@ 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>
@ -1416,7 +1416,7 @@ SELECT b, char_length(b) FROM test2;
<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>

21
doc/src/sgml/installation.sgml
View File

@ -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>