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 16:50:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> writes:
> On Tue, Mar 12, 2019 at 5:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This seems committable from my end --- any further comments?

> I gave it a read and it looks good to me, but I haven't tried to run it.

Thanks for checking. I've pushed both patches now.

I noticed while looking at the pg_class data that someone had stuck in a
hack to make substitute for "PGHEAPAM", which AFAICS is just
following the bad old precedent of PGNSP and PGUID. I got rid of that
in favor of using the already-existing BKI_LOOKUP(pg_am) mechanism.
Maybe someday we should try to get rid of PGNSP and PGUID too, although
there are stumbling blocks in the way of both:

* PGNSP is also substituted for in the bodies of some SQL procedures.

* Replacing PGUID with the actual name of the bootstrap superuser is a
bit problematic because that name isn't necessarily "postgres". We
could probably make it work, but I'm not convinced it'd be any less
confusing than the existing special-case behavior is.

Anyway I think we're basically done here. There's some additional
cleanup that could possibly be done, like removing the hard-wired
references to OID 1 in initdb.c. But I'm having a hard time convincing
myself that it's worth the trouble, except maybe for the question of
information_schema.sql's hard-wired type OIDs. Even there, it's
certainly possible for a patch to use a regtype constant even if
the existing code doesn't.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-03-12 16:59:44 Re: Use nanosleep(2) in pg_usleep, if available?
Previous Message Euler Taveira 2019-03-12 16:48:29 Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)