Why don't we have a small reserved OID range for patch revisions?
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-08T17:59:42Z
Lists: pgsql-hackers
Why don't we provide a small reserved OID range that can be used by patch authors temporarily, with the expectation that they'll be replaced by "real" OIDs at the point the patch gets committed? This would be similar the situation with catversion bumps -- we don't expect patches that will eventually need them to have them. It's considered good practice to choose an OID that's at the beginning of the range shown by the unused_oids script, so naturally there is a good chance that any patch that adds a system catalog entry will bit rot prematurely. This seems totally unnecessary to me. You could even have a replace_oids script under this system. That would replace the known-temporary OIDs with mapped contiguous real values at the time of commit (maybe it would just print out which permanent OIDs to use in place of the temporary ones, and leave the rest up to the committer). I don't do Perl, so I'm not volunteering for this. -- Peter Geoghegan
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