Re: an OID >= 8000 in master

At Wed, 20 Nov 2019 20:44:18 -0800, Peter Geoghegan <pg(at)bowt(dot)ie> wrote in
> It is still within the discretion of committers to use the
> non-reserved/development OID ranges directly. For example, a committer

That happens at feature freeze. Understood.

At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> > I thought that commits don't use the development OIDs and thought that
> > we won't have conflict perfectly.
>
> I do not think there is any easy solution that guarantees that.
> We could imagine having some sort of pre-registration mechanism,
> maybe, but it seems like more trouble than benefit.

If we don't intend what Peter pointed (arrangement of low-OIDs at
feature freeze), it can be done by moving OIDs to lower values at
commit. (I don't mean commiters should do that, it may be bothersome.)

> > By the way even if we work this way, developers tend to pick up low
> > range OIDs since it is printed at the beginning of the output. I think
> > we should hide the whole list of unused oids defaultly and just
> > suggest random one.
>
> -1, that pretty much destroys the point of the unused_oids script.

Is the "point" is what the name suggests? The tool is, for developers,
a means of finding OIDs *usable for their project*. It doesn't seem
appropriate to show OIDs that developers are supposed to refrain from
using. In my proposal the tool still shows all unused OIDs as the name
suggests when some option specified.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center