Robert Haas <robertmhaas@gmail.com> writes:
> I wasn't able to properly understand that comment, and to be honest
> I'm not sure I precisely understand your concern either. I don't quite
> see why the template0 database matters. I think that database isn't
> going to be dumped, or restored, so as far as pg_upgrade is concerned
> it might as well not exist in either cluster, and I don't see why
> pg_upgrade can't therefore just ignore it completely. But template1
> and postgres are another matter. If I understand correctly, those
> databases are going to be created in the new cluster by initdb, but
> then pg_upgrade is going to populate them with data - including
> relation files - from the old cluster.
Right. If pg_upgrade explicitly ignores template0 then its OID
need not be stable ... at least, not unless there's a chance it
could conflict with some other database OID, which would become
a live possibility if we let users get at "WITH OID = n".
(Having said that, I'm not sure that pg_upgrade special-cases
template0, or that it should do so.)
> To be honest, what I'd be inclined to do about that is just nail down
> those OIDs for future releases.
Yeah, I was thinking along similar lines.
> In fact, I'd probably go so far as to
> hardcode that in such a way that even if you drop those databases and
> recreate them, they get recreated with the same hard-coded OID.
Less sure that this is a good idea, though. In particular, I do not
think that you can make it work in the face of
alter database template1 rename to oops;
create database template1;
> The only hard requirement for this feature is if we
> use the database OID for some kind of encryption or integrity checking
> or checksum type feature.
It's fairly unclear to me why that is so important as to justify the
amount of klugery that this line of thought seems to be bringing.
regards, tom lane
