On 2017-02-22 08:43:28 -0500, Tom Lane wrote: > 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.
It sounded more like Jim suggested a full blown SQL type, given that he replied to my concern about the possible need for a deprecation period due to pg_upgrade concerns. To be useful for that, we'd need a good chunk of magic, so all existing uses of timestamp[tz] are replaced with floattimestamp[tz], duplicate some code, add implicit casts, and accept that composites/arrays won't be fixed. That sounds like a fair amount of work to me, and we'd still have no way to remove the code without causing pain. > 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. Well, the newly introduced bug was just a copy of the existing code. I'm far less negative about this than you - we're not dealing with a whole lot of code here. I don't get why it'd be foolish to verify the limited amount of code dealing with replication protocol timestamp. > 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. > (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.) I think we should just fix it in the back branches, and drop the float timestamp code in 10 or 11. I.e. 1) and then 4). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
