At Thu, 21 Nov 2019 10:35:25 -0500, Tom Lane <t...@sss.pgh.pa.us> wrote in > > 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.
Thanks for the explantion. I understood and agreed. > >>> 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. For clarity, it's perfect also to me. I don't insist on the change since no supporters come up. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
