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 |
Message-ID: | 27064.1552366578@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 |
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? |