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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
