Andres Freund <andres@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.1487456324@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.1487456324@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
