On Wed, Jul 19, 2017 at 1:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Jul 19, 2017 at 1:12 PM, Tom Lane <t...@sss.pgh.pa.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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to