Tom Lane wrote:
>
> 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.
...
>
> 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?
I was wondering in the past if it would simply be better to have an
.SQL script which is submitted to the template1 database at
post-initdb time with COMMENT ON statements to document built-in
types, functions, system relations, etc. I should, after all, be
able to issue a "\d+ pg_class" in psql and get a description of the
columns. The .SQL script could potentially contain COMMENT ON
statements localized to the language in which the database is
installed, but it wouldn't care what OIDs were assigned (if any) to
the various objects being documented.
Mike Mascari
mascarm@mascari.com
