Thread: Planned change in initdb-time OID allocation
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
> 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. This was a known problem when I implemented pg_description. Your solution sounds good. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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
Mike Mascari <mascarm@mascari.com> writes:
> 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.
The nice thing about the way it's done now is that the descriptions
sit right next to the defining commands in the catalog/*.h files.
Having to maintain a separate script file doesn't seem like a win.
Almost certainly, the descriptions would be poorly maintained ---
ye olde out-of-sight, out-of-mind problem.
regards, tom lane