Re: [HACKERS] Replication vs. float timestamps is a disaster

On Mon, Feb 20, 2017 at 09:07:33AM -0500, Tom Lane wrote:
> The question to be asked is whether there is still anybody out there
> using float timestamps.  I'm starting to get dubious about it myself.
> Certainly, no packager that I'm aware of has shipped a float-timestamp
> build since we switched the default in 8.4.  Maybe there is somebody
> who's faithfully built a float-timestamp custom build every year so they
> can pg_upgrade in place from their 8.3 installation, but there have got
> to be darn few such people.
> 
> As for "proper deprecation period", the documentation has called the
> option deprecated since 8.4:
> 
> -disable-integer-datetimes
>     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
>     PostgreSQL releases prior to 8.4, but it is now deprecated,
>     because it does not support microsecond precision for the full
>     range of timestamp values.
> 
> I think the strongest reason why we didn't move to kill it sooner was
> that we were not then assuming that every platform had 64-bit ints;
> but we've required that since 9.0.

I agree with removing support for float timestamps in PG 10.  It would
be tempting to think we can reuse the bits we stopped using in 9.0 for
VACUUM FULL, e.g.:
#define HEAP_MOVED_OFF          0x4000  /* moved to another place by pre-9.0                                         *
VACUUMFULL; kept for binary                                         * upgrade support */#define HEAP_MOVED_IN
0x8000 /* moved from another place by pre-9.0                                         * VACUUM FULL; kept for binary
                                    * upgrade support */
 

However, if users built Postgres 8.4 with integer timestamps, they could
still be in the data files.  Does anyone see a fault in my logic, I
hope?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +