Re: automatically assigning catalog toast oids

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: automatically assigning catalog toast oids
Дата
Msg-id CAJVSVGUOjo=r88a4Qu32HUjrdtc3rhvWqPnTrRir_wYgLxBE8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: automatically assigning catalog toast oids  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 12/9/18, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock
Следующее
От: John Naylor
Дата:
Сообщение: Re: docs: outdated reference to recursive expression evaluation