On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane <tgl@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? Existing values will be silently
reinterpreted according to the new rules. 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. If
this type is so marginal that we don't want to do that kind of work,
then I think we should just rip it out; that doesn't preclude someone
maintaining it in their own fork, or even adding it back as a new type
in a contrib module with a #define for the base year. Silently
changing the interpretation of the same data in the core code, though,
seems both far too clever and not clever enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company