Re: automatically assigning catalog toast oids
John Naylor <jcnaylor@gmail.com>
From: John Naylor <jcnaylor@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Stephen Frost <sfrost@snowman.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-12-10T14:49:24Z
Lists: 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
Commits
-
Fix typo in transam.h for OIDs assigned by genbki.pl
- f0cce9fcb5fd 12.0 landed
-
Create a separate oid range for oids assigned by genbki.pl.
- 09568ec3d31b 12.0 landed
-
Remove WITH OIDS support, change oid catalog column visibility.
- 578b229718e8 12.0 cited
-
Add toast tables to most system catalogs
- 96cdeae07f93 12.0 cited