From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Oid registry |
Date: | 2012-09-25 14:23:47 |
Message-ID: | 18594.1348583027@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Given your previous comments, perhaps we could just start handing out
> Oids (if there is any demand) numbered, say, 9000 and up. That should
> keep us well clear of any existing use.
No, I think you missed my point entirely: handing out OIDs at the top
of the manual assignment range is approximately the worst possible
scenario. I foresee having to someday move FirstBootstrapObjectId
down to 9000, or 8000, or even less, to cope with growth of the
auto-assigned OID set. So we need to keep manually assigned OIDs
reasonably compact near the bottom of the range, and it doesn't matter
at all whether such OIDs are used internally or reserved for external
developers. Nor do I see a need for such reserved OIDs to "look
different" from internally-used OIDs. Reserved is reserved.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-25 14:30:59 | Re: Patch: incorrect array offset in backend replication tar header |
Previous Message | Simon Riggs | 2012-09-25 14:05:55 | Re: xlog filename formatting functions in recovery |