Assigning fixed OIDs to system catalogs and indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Assigning fixed OIDs to system catalogs and indexes
Date: 2005-04-12 21:19:01
Message-ID: 29990.1113340741@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While thinking about the use of hand-assigned OIDs for pg_proc and
pg_operator, it occurred to me to wonder why we don't have hand-assigned
OIDs for all system catalogs and indexes. Currently, most of the time
that the C code wants to reference a specific catalog or index, it has
to reference it by name. If we had fixed OIDs for all the catalogs and
indexes known to the C code, we could get rid of heap_openr,
index_openr, and the index-by-name maintained inside the relcache,
because *all* such accesses would go by OID. I don't have hard numbers
to prove it, but I think that the aggregate overhead of doing string
instead of integer comparisons during those lookups has to be
nontrivial. There are other annoyances such as having to use
get_system_catalog_relid() in many places where a constant would be nice
to have.

The code wouldn't get any less readable -- we'd just be replacing macros
that expand to strings with ones that expand to numbers.

Thoughts? Anyone have an argument why we should not do this?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2005-04-13 01:47:55 Re: Assigning fixed OIDs to system catalogs and indexes
Previous Message Tom Lane 2005-04-12 21:09:46 Simplifying bootstrap OID assignment