[Tom Lane <tgl@sss.pgh.pa.us>]

Andres Freund <andres@anarazel.de> writes:
> On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I'm a bit dubious that this is a good idea.  It's handy, at least for
> forensic situations, that the system catalogs have stable OIDs.

> Hm, but won't they have that for major versions anyway? We ought not to
> change the .bki generation in a way that results in differing oids after
> a release, no?

Well, that's just a different very-easily-broken assumption.  There are
a lot of things that make auto-assigned OIDs unstable, and I do not think
that we want to guarantee that they'll hold still across a release series.

BTW, now that I'm looking at it, I very much dislike the way commit
578b2297 handled auto-assignment of OIDs in catalogs.  Not only do I not
want to assign more OIDs that way, I don't think we can safely ship v12
like this.  There's basically nothing at all that guarantees
genbki-assigned OIDs won't overlap initdb-assigned OIDs.  In fact,
I think it's about guaranteed to blow up in the face of anybody who
inserts manually-assigned OIDs above around 9000.

What we probably need to do is restructure the FirstBootstrapObjectId
business so that there are separate, well-defined ranges for genbki.pl
and initdb to use.

			regards, tom lane