Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> So, thinking about how that would actually work ... the thing to do in >> order to preserve existing on-disk values is to alternate between signed >> and unsigned interpretations of abstimes. That is, right now, abstime >> is signed with origin 1970. The conversion I'm arguing we should make >> real soon now is to unsigned with origin 1970. If the project lives >> so long, in circa 70 years we'd switch it to signed with origin 2106. >> Yadda yadda.
> Doesn't this plan amount to breaking pg_upgrade compatibility and > hoping that nobody notice? Well, what we'd need to do is document that the type is only meant to be used to store dates within say +/- 30 years from current time. As long as people adhere to that use-case, the proposal would work conveniently long into the future ... > If we had two actually > separate types and let people convert columns from the old type to the > new type with just a validation scan, that would be engineering at the > level of quality that I've come to associate with this project. ... whereas that would be seriously INconvenient. It's not just the ALTER TABLE pushups, which presumably would be something you could do and forget. It's that the new type name would be something you'd have to change your applications to know about, and then you (or more likely your successor) would have to do it over again decades later. I'd definitely be on board with just dropping the type altogether despite Mark's concern. But I am not sure that the way you are proposing would please anybody except pedants. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers