Re: Why don't we have a small reserved OID range for patch revisions?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-03-01T19:36:50Z
Lists: pgsql-hackers
On Thu, Feb 28, 2019 at 6:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 1. Encourage people to develop new patches using chosen-at-random > high OIDs, in the 7K-9K range. They do this already, it'd just > be encouraged instead of discouraged. > > 2. Commit patches as received. > > 3. Once each devel cycle, after feature freeze, somebody uses the > renumbering tool to shove all the new OIDs down to lower numbers, > freeing the high-OID range for the next devel cycle. We'd have > to remember to do that, but it could be added to the RELEASE_CHANGES > checklist. Sure, that sounds nice. It seems like it might be slightly less convenient for non-committers than what I was proposing, but still more convenient than what they're doing right now. And it's also more convenient for committers, because they're not being asked to manually fiddle patches at the last moment, something that I at least find rather error-prone. It also, and I think this is really good, moves in the direction of fewer things for both patch authors and patch committers to worry about doing wrong. Instead of throwing rocks at people whose OID assignments are "wrong," we just accept what people do and adjust it later if it makes sense to do so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Remove remaining hard-wired OID references in the initial catalog data.
- 3aa0395d4ed3 12.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 landed
-
Minor improvements for reformat_dat_file.pl.
- 27aaf6eff49a 12.0 landed