Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Wed, 20 Nov 2019 23:45:21 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
>> 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.)
Yes, that's exactly the point: when we discussed this new policy,
it was agreed that making committers deal with the issue in each
commit was an unreasonable burden. Aside from just being more
work, there's the risk that two committers working on different
patches concurrently would choose to map the development OIDs to
the same "final" OIDs. It seems better to deal with the problem
once at feature freeze.
Anyway, we've only had this policy in place for a few months.
I'm not eager to redesign it until we've had more experience.
>>> 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.
The existing output seems perfectly clear to me. What you propose
just adds complication and reduces usefulness.
regards, tom lane
