Re: Planned change in initdb-time OID allocation - Mailing list pgsql-hackers

From Mike Mascari
Subject Re: Planned change in initdb-time OID allocation
Date
Msg-id 3B6F578F.3135683A@mascari.com
Whole thread Raw
In response to Planned change in initdb-time OID allocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Planned change in initdb-time OID allocation
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Planned change in initdb-time OID allocation
Next
From: Tom Lane
Date:
Subject: Re: Planned change in initdb-time OID allocation