On 2017-02-19 10:49:29 -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Sun, Feb 19, 2017 at 3:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Thoughts? Should we double down on trying to make this work according > >> to the "all integer timestamps" protocol specs, or cut our losses and > >> change the specs? > > > I vote for doubling down. It's bad enough that we have so many > > internal details that depend on this setting; letting that cascade > > into the wire protocol seems like it's just letting the chaos spread > > farther and wider. > > How do you figure that it's not embedded in the wire protocol already? > Not only the replicated data for a timestamp column, but also the > client-visible binary I/O format, depend on this. I think having some > parts of the protocol use a different timestamp format than other parts > is simply weird, and as this exercise has shown, it's bug-prone as all > get out.
I don't think it's that closely tied together atm. Things like pg_basebackup, pg_receivexlog etc should work, without having to match timestamp storage. Logical replication, unless your output plugin dumps data in binary / "raw" output, also works just fine across the timestamp divide. It doesn't sound that hard to add a SystemToIntTimestamp() function, given it only needs to do something if float timestamps are enabled? Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
