Presently, we have hand-assigned OIDs running up to about 1950
(according to the unused_oids script). The range up to 16K is reserved
for hand-assigned OIDs, and the OID counter starts at 16384 at initdb.
A peek in pg_database shows datlastsysoid = 18931 in current sources, so
a total of about 2550 OIDs are machine-assigned during initdb. The bulk
of these last are in pg_attribute (827 rows) and pg_description (1221
rows).
All the hand-assigned OIDs are established by lines like
DATA(insert OID = 23 ( int4 PGUID 4 10 t b t \054 0 0 int4in int4out int4in int4out i p _null_ ));
in catalog include files. We also have lines like
DATA(insert OID = 0 ( avg PGUID int4_accum numeric_avg 23 1231 1700 "{0,0,0}" ));
which do not assign a specific OID to the row --- instead the row will
receive a machine-generated OID (at or above 16k) when it is loaded.
What bothers me about this scheme is that genbki.sh can only create
pg_description entries for objects with hand-assigned OIDs. It
processes the DESCR() macro by emitting the OID of the last DATA macro,
along with the description text, into a data file that's eventually
copied into pg_description. But if there's no hand-assigned OID it has
to punt --- it doesn't know what OID the object will have. This means
we can't assign initdb-time descriptions to aggregate functions (for
example), since we don't give them hand-assigned OIDs.
There are a couple of possible ways to attack this, but the one that
seems best to me is to allow genbki.sh itself to assign OIDs to DATA
lines that don't have one. It could start at, say, 10000, staying well
clear of both the hand-assigned OIDs and the ones that will be generated
on-the-fly by the backend. Then it would know the correct OID to
associate with any DESCR macro.
Comments, objections?
regards, tom lane
