Robert Haas <robertmhaas@gmail.com> writes:
> This seems like a big piece of new mechanism being invented
> to solve an occasional annoyance. Your statistics are not convincing
> at all: you're arguing that this is a big problem because 2-3% of
> pending patches current have an issue here, and some others have in
> the past, but that's a really small percentage, and the time spent
> doing OID renumbering must be a tiny percentage of the total time
> anyone spends hacking on PostgreSQL.
TBH, I find this position utterly baffling. It's true that only a
small percentage of patches have an issue here, because only a small
percentage of patches dabble in manually-assigned OIDs at all. But
*among those that do*, there is a huge problem. I had not actually
realized how bad it is until I gathered those stats, but it's bad.
I don't understand the objection to inventing a mechanism that will
help those patches and has no impact whatever when working on patches
that don't involve manually-assigned OIDs.
And, yeah, I'd like us not to have patches hanging around for years
either, but that's a reality that's not going away.
> We could fix that problem by caring less about keeping all the numbers
> gapless and increasing the size of the reserved space to say 100k,
We already had this discussion. Moving FirstNormalObjectId is infeasible
without forcing a dump/reload, which I don't think anyone wants to do.
> but
> just as a thought, what if we stopped assigning manual OIDs for new
> catalog entries altogether, except for once at the end of each release
> cycle?
And that's another idea without any basis in reality. What are you
going to do instead? What mechanism will you use to track these
OIDs so you can clean up later? Who's going to write the code that
will support this? Not me. I think the proposal that is on the
table is superior.
regards, tom lane