Re: Last builtin OID?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Philip Warner writes:
>> pg_dump uses the OID of template1 as the last builtin OID, but this now
>> seems broken in CVS (it returns 1). Should this work? If not, what is the
>> recommended way to find the last built-in OID?

> If you define the last builtin oid as the highest oid in existence after
> initdb then it has always been whatever the load of pg_description at then
> end leaves you with.

"select max(oid) from pg_description" won't do, unfortunately, since the
user might add more comments after creating objects of his own. Ugh.

> Perhaps you could move the CREATE TRIGGER pg_sync_pg_pwd (or something
> else) to the very end to get a more predictable starting point.

This seems pretty fragile; I'd rather not rely on the assumption that
some specific item is the last one created by initdb.

The reason this isn't simple is that we have a bunch of rows with
hard-wired OIDs (all the ones specifically called out in
include/catalog) plus a bunch more with non-hard-wired OIDs (if they
don't need to be well-known, why keep track of them?). We initialize
the OID counter to 16384, above the last hard-wired OID, so that the
non-hard-wired OIDs start there. But there's no way to be sure where
the non-hard-wired system OIDs stop and user OIDs begin.

What if we specify a definite range for these "soft system OIDs"?
Say, 1-16383 are for hardwired OIDs as now, 16384-32767 for soft OIDs,
and user OIDs start at 32768. Then pg_dump's task is easy; it just
uses the latter constant from some include file. We could implement
this by initializing the OID counter at 16384 as now, and then rewriting
it to 32768 at the end of initdb.

Comments?

BTW, this raises a point I'd never thought hard about: if the dbadmin
adds some site-local objects to template1, then makes databases that
copy these objects, a pg_dumpall and restore will do the Wrong Thing.
pg_dump isn't smart about excluding objects inherited from template1
from dumps of other databases. Is there any reasonable way to fix
that?

regards, tom lane