PostgreSQL 安裝期間內置（又名標準）數據庫對象的 OID 版本範圍
軟體通常為安裝或更新檔/升級期間創建的對象的標準對象（PostgreSQL 將這些“內置”對象）的標識符保留 id 發布範圍。我很難找到 PostgreSQL 對象的 OID 版本範圍。有人可以指出我的文件嗎？此外，OID 是否正在逐步退出 PostgreSQL？這將如何影響我的問題？
例如，pg_roles 表似乎對安裝期間創建的對像或更新檔使用四位數或更少的 OID，但文件有限。這是我能找到的最接近的東西。
https://www.postgresql.org/docs/12/release-12.html
為新的內置對象（例如新函式）手動分配 OID 的更新檔現在應該在 8000-9999 範圍內隨機選擇 OID。在開發週期結束時，已送出更新檔使用的 OID 將使用新的 renumber_oids.pl 腳本重新編號為較低的數字，目前在 4xxx 範圍內。這種方法應該會大大降低不同程序內更新檔之間 OID 衝突的機率。
雖然沒有保留任何 OID 供外部使用的特定政策，但建議分叉和其他需要私有手動分配 OID 的項目使用高 7xxx 範圍內的數字。這將避免與最近合併的更新檔發生衝突，並且核心項目應該需要很長時間才能達到該範圍。
鑑於上面的引用，也許更好的提問方式是“用於每種類型的新對象創建（即：pg_roles）的 OID 種子值或 OID 算法是什麼？”
雖然沒有保留任何 OID 供外部使用的具體政策
系統對象的 OID 範圍
1為16383.在 PostgreSQL 包含文件中，
server/access/transam.h有關於如何分配 OID 的展示文稿，這可能會有所幫助：/* ---------- * Object ID (OID) zero is InvalidOid. * * OIDs 1-9999 are reserved for manual assignment (see .dat files in * src/include/catalog/). Of these, 8000-9999 are reserved for * development purposes (such as in-progress patches and forks); * they should not appear in released versions. * * OIDs 10000-11999 are reserved for assignment by genbki.pl, for use * when the .dat files in src/include/catalog/ do not specify an OID * for a catalog entry that requires one. Note that genbki.pl assigns * these OIDs independently in each catalog, so they're not guaranteed * to be globally unique. Furthermore, the bootstrap backend and * initdb's post-bootstrap processing can also assign OIDs in this range. * The normal OID-generation logic takes care of any OID conflicts that * might arise from that. * * OIDs 12000-16383 are reserved for unpinned objects created by initdb's * post-bootstrap processing. initdb forces the OID generator up to * 12000 as soon as it's made the pinned objects it's responsible for. * * OIDs beginning at 16384 are assigned from the OID generator * during normal multiuser operation. (We force the generator up to * 16384 as soon as we are in normal operation.) * * The choices of 8000, 10000 and 12000 are completely arbitrary, and can be * moved if we run low on OIDs in any category. Changing the macros below, * and updating relevant documentation (see bki.sgml and RELEASE_CHANGES), * should be sufficient to do this. Moving the 16384 boundary between * initdb-assigned OIDs and user-defined objects would be substantially * more painful, however, since some user-defined OIDs will appear in * on-disk data; such a change would probably break pg_upgrade. * * NOTE: if the OID generator wraps around, we skip over OIDs 0-16383 * and resume with 16384. This minimizes the odds of OID conflict, by not * reassigning OIDs that might have been assigned during initdb. Critically, * it also ensures that no user-created object will be considered pinned. * ---------- */ #define FirstGenbkiObjectId 10000 #define FirstUnpinnedObjectId 12000 #define FirstNormalObjectId 16384如果您出於某種原因在系統範圍內需要自己的 OID，我認為這將屬於“分叉”類別，因此在
8000-9999範圍內。問：另外，OID 是否正在從 PostgreSQL 中逐步淘汰？
不，但是 OID 列在 Postgres 12 中被降級為“普通”列，而不是系統列。在 Postgres 的演變過程中，將 OID 規範化為普通的每個表的數字主鍵，而不是它們在原始設計中的“全域唯一主鍵”，這是一個漸進的過程。例如，請參閱部落格文章OIDs 降級為普通列：關於這種演變的過去一瞥。這不是要逐步淘汰 OID，而是要確保它們不會妨礙進展。
問：例如，pg_roles 表似乎對安裝期間創建的對像或更新檔使用四位或更少的 OID
pg_roles本身不是一張桌子，它是一個視圖。它的一列名為oid，其值來自pg_authid.oid。它是 的主鍵pg_authid。這實際上與安裝沒有太大關係，除了創建的系統角色（通常postgres）具有oid低於 的值16384，而安裝後創建的角色使用CREATE USERorCREATE ROLE將具有oid高於 的值16384。