From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <hornschnorter(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Something for the TODO list: deprecating abstime and friends |
Date: | 2017-07-19 18:18:22 |
Message-ID: | CA+TgmoY3gPi000nWof_bSQ+W6ds46D1_pcfJKWRivt6jRd9_jA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'd definitely be on board with just dropping the type altogether despite
>>> Mark's concern.
>
>> Then I vote for that option.
>
> BTW, another possible compromise is to move abstime into a contrib
> module; we've always accepted that contrib modules can be held to a
> lower standard than core features. I'm not volunteering to do the
> work for that, but it's worth contemplating.
I would be OK with that, provided the documentation calls out the hazard.
> Alternatively, we could turn the origin point for abstime into
> pg_control field, and regard changing it as a reason for a database
> not being pg_upgrade'able unless it lacks any abstime columns.
I would be OK with that, too, but is there any danger that we're going
to grow pg_control to a size where reads and writes can no longer be
assumed atomic, if we keep adding things?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-07-19 18:23:52 | Re: PG10b2: column-list UPDATE syntax fails with single column |
Previous Message | Tom Lane | 2017-07-19 18:09:22 | Re: pl/perl extension fails on Windows |