Robert Haas <robertmh...@gmail.com> writes: >>> just as a thought, what if we stopped assigning manual OIDs for new >>> catalog entries altogether, except for once at the end of each release >>> cycle?
Actually ... that leads to an idea that wouldn't add any per-commit overhead, or really much change at all to existing processes. Given the existence of a reliable OID-renumbering tool, we could: 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. In this scheme, OID collisions are a problem for in-progress patches only if two patches are unlucky enough to choose the same random high OIDs during the same devel cycle. That's unlikely, or at least a good bit less likely than collisions are today. If/when it does happen we'd have a couple of alternatives for ameliorating the problem --- either the not-yet-committed patch could use the renumbering tool on their own OIDs, or we could do an off-schedule run of step 3 to get the already-committed OIDs out of their way. regards, tom lane