| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| 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 17:35:59 |
| Message-ID: | 5288.1500485759@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Alternatively, we could turn the origin point for abstime into a
pg_control field, and regard changing it as a reason for a database
not being pg_upgrade'able unless it lacks any abstime columns.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-07-19 17:42:05 | Re: Using non-sequential timelines in order to help with possible collisions |
| Previous Message | Robert Haas | 2017-07-19 17:29:17 | Re: Cache lookup errors with functions manipulation object addresses |