> On Jul 19, 2017, at 9:53 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
This is what I have done in my fork. I repurposed the type as "secondstamp"
since I think of it as a timestamp down to second precision (truncating
fractional seconds.) I changed the Oids assigned to the catalog entries
associated with the type, and considered myself somewhat immune to
the project dropping the abstime type, which the documentation warned
would happen eventually.
> 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.
I would be happy to contribute the "secondstamp" type as part of a patch
that removes the abstime type. I can add a catalog table that holds the
epoch, and add documentation for the type stating that every time the
epoch changes, their data will be automatically reinterpreted, and as such
they should only use the datatype if that is ok.
Under this plan, users with abstime columns who upgrade to postgres 11
will not have an easy time, because the type will be removed. But that is
the same and no worse than what they would get if we just remove the
abstime type in postgres 11 without any replacement.
I'm not implementing any of this yet, as I expect further objections.
Thoughts?
mark