Re: Floating-point timestamps versus Range Types

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Floating-point timestamps versus Range Types
Date: 2010-10-18 19:01:06
Message-ID: AANLkTik++iKKEBwv1P7=upGXEFKrRGvQaYkbUth7oCb2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> A reasonable conversion path might be to offer integer timestamps using
> a different type name (e.g. inttimestamp) that always means integer
> timestamps. Then, they could convert using ALTER TABLE, then do an
> in-place upgrade. We could even make pg_upgrade optionally convert
> inttimestamp to timestamp in O(1) on an integer-timestamps build.

I think in retrospect it would certainly have been better to make
integer timestamps and float timestamps two separate data types,
rather than two versions of the same data type. Whether it's worth
providing that now after the fact is not clear to me. I'd be inclined
to wait and see whether we get many complaints...

One problem with changing types in pg_upgrade is that type OIDs can
get embedded in the on-disk representation - I believe that this
happens for arrays, for instance. So I think it's practical for
pg_upgrade to change type names during a version upgrade, but not type
OIDs.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-18 19:02:15 Re: create tablespace fails silently, or succeeds improperly
Previous Message Tom Lane 2010-10-18 18:59:19 Re: create tablespace fails silently, or succeeds improperly