database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

De-support floating-point timestamps.

Browse Source 
Per discussion, the time has come to do this.  The handwriting has been
on the wall at least since 9.0 that this would happen someday, whenever
it got to be too much of a burden to support the float-timestamp option.
The triggering factor now is the discovery that there are multiple bugs
in the code that attempts to implement use of integer timestamps in the
replication protocol even when the server is built for float timestamps.
The internal float timestamps leak into the protocol fields in places.
While we could fix the identified bugs, there's a very high risk of
introducing more.  Trying to build a wall that would positively prevent
mixing integer and float timestamps is more complexity than we want to
undertake to maintain a long-deprecated option.  The fact that these
bugs weren't found through testing also indicates a lack of interest
in float timestamps.

This commit disables configure's --disable-integer-datetimes switch
(it'll still accept --enable-integer-datetimes, though), removes direct
references to USE_INTEGER_DATETIMES, and removes discussion of float
timestamps from the user documentation.  A considerable amount of code is
rendered dead by this, but removing that will occur as separate mop-up.

Discussion: https://postgr.es/m/26788.1487455319@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2017-02-23 11:40:12 -05:00
parent c3368f9173
commit b6aa17e0ae
15 changed files with 36 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -7695,11 +7695,9 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</term>
<listitem>
<para>
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>.
Reports whether <productname>PostgreSQL</> was built with support for
64-bit-integer dates and times. As of <productname>PostgreSQL</> 10,
this is always <literal>on</literal>.
</para>
</listitem>
</varlistentry>

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

@ -1580,7 +1580,7 @@ SELECT E'\\xDEADBEEF';
<entry>both date and time (no time zone)</entry>
<entry>4713 BC</entry>
<entry>294276 AD</entry>
<entry>1 microsecond / 14 digits</entry>
<entry>1 microsecond</entry>
</row>
<row>
<entry><type>timestamp [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
@ -1588,7 +1588,7 @@ SELECT E'\\xDEADBEEF';
<entry>both date and time, with time zone</entry>
<entry>4713 BC</entry>
<entry>294276 AD</entry>
<entry>1 microsecond / 14 digits</entry>
<entry>1 microsecond</entry>
</row>
<row>
<entry><type>date</type></entry>
@ -1604,15 +1604,15 @@ SELECT E'\\xDEADBEEF';
<entry>time of day (no date)</entry>
<entry>00:00:00</entry>
<entry>24:00:00</entry>
<entry>1 microsecond / 14 digits</entry>
<entry>1 microsecond</entry>
</row>
<row>
<entry><type>time [ (<replaceable>p</replaceable>) ] with time zone</type></entry>
<entry>12 bytes</entry>
<entry>times of day only, with time zone</entry>
<entry>time of day (no date), with time zone</entry>
<entry>00:00:00+1459</entry>
<entry>24:00:00-1459</entry>
<entry>1 microsecond / 14 digits</entry>
<entry>1 microsecond</entry>
</row>
<row>
<entry><type>interval [ <replaceable>fields</replaceable> ] [ (<replaceable>p</replaceable>) ]</type></entry>
@ -1620,7 +1620,7 @@ SELECT E'\\xDEADBEEF';
<entry>time interval</entry>
<entry>-178000000 years</entry>
<entry>178000000 years</entry>
<entry>1 microsecond / 14 digits</entry>
<entry>1 microsecond</entry>
</row>
</tbody>
</tgroup>
@ -1643,41 +1643,7 @@ SELECT E'\\xDEADBEEF';
<replaceable>p</replaceable> which specifies the number of
fractional digits retained in the seconds field. By default, there
is no explicit bound on precision. The allowed range of
<replaceable>p</replaceable> is from 0 to 6 for the
<type>timestamp</type> and <type>interval</type> types.
</para>
<note>
<para>
When <type>timestamp</> values are stored as eight-byte integers
(currently the default), microsecond precision is available over
the full range of values. In this case, the internal representation
is the number of microseconds before or after midnight 2000-01-01.
When <type>timestamp</> values are stored as double precision
floating-point numbers (a deprecated compile-time option), the
internal representation is the number of seconds before or after
midnight 2000-01-01. With this representation, the effective limit
of precision might be less than 6; in practice,
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>
<para>
For the <type>time</type> types, the allowed range of
<replaceable>p</replaceable> is from 0 to 6 when eight-byte integer
storage is used, or from 0 to 10 when floating-point storage is used.
<replaceable>p</replaceable> is from 0 to 6.
</para>
<para>
@ -1760,9 +1726,10 @@ MINUTE TO SECOND
specification giving the number of
fractional digits in the seconds field. Precision can be
specified for <type>time</type>, <type>timestamp</type>, and
<type>interval</type> types. The allowed values are mentioned
above. If no precision is specified in a constant specification,
it defaults to the precision of the literal value.
<type>interval</type> types, and can range from 0 to 6.
If no precision is specified in a constant specification,
it defaults to the precision of the literal value (but not
more than 6 digits).
</para>
<sect3>

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

@ -955,28 +955,6 @@ su - postgres
</listitem>
</varlistentry>
<varlistentry>
<term><option>--disable-integer-datetimes</option></term>
<listitem>
<para>
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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--disable-float4-byval</option></term>
<listitem>