From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: an OID >= 8000 in master |
Date: | 2019-11-21 04:44:18 |
Message-ID: | CAH2-WzkWT03g9yGdJYu_3yoqxmm9i3ya-VxOGcU6h_Vzfmfr0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 20, 2019 at 8:33 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> So, still any ongoing patch can stamp on another when it is committed
> by certain probability (even if it's rather low)). And consecutive
> high-OID "hole"s are going to be shortened and decrease throgh a year.
Right.
> 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.
It is still within the discretion of committers to use the
non-reserved/development OID ranges directly. For example, a committer
may prefer to use an OID that is close to the OIDs already used for a
set of related objects, if the related objects are already in a stable
release. (I'm not sure that it's really worth doing that, but that's
what the policy is.)
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-21 04:45:21 | Re: an OID >= 8000 in master |
Previous Message | Kyotaro Horiguchi | 2019-11-21 04:33:48 | Re: an OID >= 8000 in master |