Re: Why don't we have a small reserved OID range for patch revisions?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why don't we have a small reserved OID range for patch revisions?
Date: 2019-03-12 04:56:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> I've successfully done check-world after renumbering every OID above
> 4000 to somewhere else. I also tried renumbering everything below
> 4000, which unsurprisingly blew up because there are various catalog
> columns we haven't fixed to use symbolic OIDs. (The one that initdb
> immediately trips over is pg_database.dattablespace.) I'm not sure
> if it's worth the trouble to make that totally clean, but I suspect
> we ought to at least mop up text-search references to be symbolic.
> That's material for a separate patch though.

So I couldn't resist poking at that, and after a couple hours' work
I have the attached patch, which removes all remaining hard-wired
OID references in the .dat files.

Using this, I renumbered all the OIDs in include/catalog, and behold
things pretty much worked. I got through check-world after hacking
up these points:

* Unsurprisingly, there are lots of regression tests that have object
OIDs hard-wired in queries and/or expected output.

* initdb.c has a couple of places that know that template1 has OID 1.

* information_schema.sql has several SQL-language functions that
hard-wire the OIDs of assorted built-in types.

I'm not particularly fussed about the first two points, but the
last is a bit worrisome. It's not too hard to imagine somebody
adding knowledge of their new type to those functions, and the
code getting broken by a renumbering pass, and us not noticing
if the point isn't stressed by a regression test (which mostly
those functions aren't).

We could imagine fixing those functions along the lines of

CASE WHEN $2 = -1 /* default typmod */
THEN null
- WHEN $1 IN (1042, 1043) /* char, varchar */
+ WHEN $1 IN ('pg_catalog.bpchar'::pg_catalog.regtype,
+ 'pg_catalog.varchar'::pg_catalog.regtype)
THEN $2 - 4

which would add some parsing overhead, but I'm not sure if anyone
would notice that.

regards, tom lane

Attachment Content-Type Size
clean-up-oid-references.patch text/x-diff 29.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-03-12 05:01:26 Re: Suggestions on message transfer among backends
Previous Message Kyotaro HORIGUCHI 2019-03-12 03:45:59 Re: [Suspect SPAM] Re: Should we increase the default vacuum_cost_limit?