Andres Freund <and...@anarazel.de> writes: > On 2017-02-22 00:10:35 -0600, Jim Nasby wrote: >> I wounder if a separate "floatstamp" data type might fit the bill there. It >> might not be completely seamless, but it would be binary compatible.
> I don't really see what'd that solve. Seems to me this is a different name for what I already tried in <27694.1487456...@sss.pgh.pa.us>. It would be much better than doing nothing, IMO, but it would still leave lots of opportunities for mistakes. To review the bidding a bit, it seems to me we've got four possible ways of dealing with this issue: 1. Just patch the already-identified float-vs-int-timestamp bugs in as localized a fashion as possible, and hope that there aren't any more and that we never introduce any more. I find this hope foolish :-(, especially in view of the fact that what started this discussion is a newly-introduced bug of this ilk. 2. Introduce some new notation, perhaps <27694.1487456...@sss.pgh.pa.us> plus new "sendtimestamp" and "recvtimestamp" functions, to try to provide some compiler-assisted support for getting it right. 3. Give up on "protocol timestamps are always integer style". 4. Give up on float timestamps altogether. 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. I think it was clear from the day we switched to integer timestamps as the default that the days of float timestamps were numbered, and that we were only going to continue to support them as long as it wasn't costing a lot of effort. We have now reached a point at which it's clear that continuing to support them will have direct and significant costs. I say it's time to pull the plug. (To be concrete, I'm suggesting dropping --disable-integer-datetimes in HEAD, and just agreeing that in the back branches, use of replication protocol with float-timestamp servers is not supported and we're not going to bother looking for related bugs there. Given the lack of field complaints, I do not believe anyone cares.) 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