PostgreSQL：regclass / oid列はバックアップ間で保持されますか？
スキーマとテーブルのリレーションIDを格納する大きなテーブル（監査）があります。これは、TG_RELIDを使用したトリガーによって便利に入力されます。また、インデックスを付けることができ、「スキーマ」（テキスト）列と「テーブル」（テキスト）列を別々に格納してインデックスを付ける場合よりもインデックスが小さくなるため、便利です。また、WHERE relation_id = 'myschema:mytable'::regclassを使用してクエリを実行できます。
私の質問は、これがバックアップ/復元の観点から「安全」であるかどうかです（schema.tableは、ターゲットサーバーとソースサーバーで同じregclass/oidを持っていますか？
他に知っておくべき問題はありますか？
私は、OIDの特定の値が移植可能であることに依存しませんまったく。試してみて現在のバージョンのPostgreSQLで動作することがわかったとしても、新しいリリースでは動作しない可能性があります /。
ソースマシンでデータベースをバックアップし、すでに他のデータベース、スキーマなどを持っている別のマシン（または、一般に、別の PostgreSQL Database Cluster ）に復元しようとすると、非常にソースデータベースが使用していたさまざまなOIDが、ターゲットデータベースで他のさまざまなものを表すためにすでに使用されている可能性があります。
OIDへの_schema_name.table_name_対応は、PostgreSQLのシステムテーブル内で処理されます。同等の機能が必要な場合は、を使用して、必要な動作を保証します。 to ではなく、 PostgreSQLの内部OID ではなく、実際にこの動作を_your_tables_テーブルで複製することをお勧めします。 id（シリアル）および_schema_name_、_table_name_。この方法で、データベースを安全にバックアップおよび復元でき、新しいpostgreSQLバージョンの変更を回避できる可能性があります。
トリガーで追加のルックアップが必要になる場合がありますが、将来的には多くの問題を回避できる可能性があります。
Contribモジュールpg_stat_statementsは、OIDを使用してクエリのフィンガープリントを作成します。したがって、これを自分で行うことによって得られる安定性の保証は、そのモジュールの文書化された保証と基本的に同じです。
pg_dumpを使用するときの安定性についてお話しているようです。安定性についての保証はありません。物理バックアップのみ。