From: | John Naylor <jcnaylor(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: automatically assigning catalog toast oids |
Date: | 2018-12-10 14:49:24 |
Message-ID: | CAJVSVGUOjo=r88a4Qu32HUjrdtc3rhvWqPnTrRir_wYgLxBE8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/9/18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Another thing I seriously dislike is that this allows people to omit OIDs
> from .dat entries in catalogs where we traditionally hand-assign OIDs.
> That's not a good idea because it would mean those entries don't have
> stable OIDs, whereas the whole point of hand assignment is to ensure
> all built-in objects of a particular type have stable OIDs. Now, you
> could argue about the usefulness of that policy for any given catalog;
> but if we decide that catalog X doesn't need stable OIDs then that should
> be an intentional policy change, not something that can happen because
> one lazy hacker didn't follow the policy.
On this point, I believe this could have happened anyway. pg_opclass
has a mix of hand- and initdb-assigned oids, and there was nothing
previously to stop that from creeping into any other catalog, as far
as I can tell.
-John Naylor
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2018-12-10 14:55:11 | Re: docs: outdated reference to recursive expression evaluation |
Previous Message | Andrey Borodin | 2018-12-10 13:58:02 | Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock |