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 по дате отправления: