Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> While I'm generally not one to vote for dropping backwards-compatibility >> features, I have to say that I find #4 the most attractive of these >> options. It would result in getting rid of boatloads of under-tested >> code, whereas #2 would really just add more, and #3 at best maintains >> the status quo complexity-wise.
> +1. BTW, I did a bit of digging in the archives, and found a couple of previous discussions around this: https://www.postgresql.org/message-id/flat/1178476313.18303.164.camel%40goldbach https://www.postgresql.org/message-id/flat/1287334597.8516.372.camel%40jdavis as well as numerous discussions of specific bugs associated with float timestamps, eg this isn't even the first time we've hit a float-timestamp replication bug: https://www.postgresql.org/message-id/flat/CAHGQGwFbqTDBrw95jek6_RvYG2%3DE-6o0HOpbeEcP6oWHJTLkUw%40mail.gmail.com In one or another of those threads, I opined that we'd have to keep float timestamps available for as long as we were supporting pg_upgrade from 8.3. However, I think that that argument hasn't really stood the test of time, because of the lack of packagers shipping builds with float timestamps turned on. There may be some number of installations that still have float timestamps active, but it's got to be a tiny number. And the list of reasons not to like float timestamps is very long. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers