Re: Planned change in initdb-time OID allocation

From: Mike Mascari <mascarm(at)mascari(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planned change in initdb-time OID allocation
Date: 2001-08-07 02:50:55
Message-ID: 3B6F578F.3135683A@mascari.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)mascari(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-08-07 02:51:10 Re: Planned change in initdb-time OID allocation
Previous Message Tom Lane 2001-08-07 02:43:03 Re: FTI contrib