5

database_a に外部テーブル ( foo_table) を作成しています。foo_tabledatabase_b に住んでいます。 foo_table列の 1 つとして列挙型 ( bar_type) があります。この列挙型は database_b にあるため、database_a での外部テーブルの作成は失敗します。database_a は列の型を認識していません。database_a で以下を実行

CREATE FOREIGN TABLE foo_table (id integer NOT NULL, bar bar_type) SERVER database_b

エラーが発生します：

ERROR: type "bar_type" does not exist

database_a にのコピーを作成することもできbar_typeますが、これは重複しているように感じられ、将来の不整合の原因になる可能性があります。取り扱いのベストプラクティスについて考えている人はいますか?

4

3 に答える 3

8

pgsql-general メーリング リストから受け取った回答を要約します。

  1. 外部テーブルは基本的にローカル データベースのアドホック リモート データ ソースであるため、別の (または同じ) PostgreSQL サーバーにあるか、まったく異なるサーバーにあるかに関係なく、リモート テーブルの定義を維持する責任はローカル データベースにあります。特に、ローカルの定義がリモートの定義と異なる場合があるためです。
  2. これは、リモートの依存関係がローカル サーバーに存在することを確認する簡単な方法がないことを意味します。PostgreSQL 9.5 は IMPORT FOREIGN SCHEMA コマンドを提供しますが、これはテーブル/ビュー定義に限定されます。
  3. enum の定義に一貫性がなくなると、ローカル側で不明な値を持つ行を取得するときにエラーが発生することが予想されます。
  4. これを回避する方法の 1 つは、外部テーブルの列を列挙型ではなく「テキスト」として宣言することです。ローカル側で一部のエラー チェックが失われますが、リモート サーバーは何かを保存するたびに有効性を強制します。
  5. ただし、このハックが enum 列の WHERE 条件に対して望ましい動作をするかどうかは明確ではありません。WHERE 条件のパフォーマンスを確認し、詳細がわかり次第、この回答を更新します。

すべての功績は、pgsql-general メーリング リストの善良な人々に送られます。

于 2015-05-28T18:28:54.913 に答える
0

本当のピンチで（そして、列挙型/ドメインが多すぎない場合）。インポートを実行する前に、新しいローカルの外部スキーマにそれぞれを手動で作成すると機能します。

私の場合postgres_fdw、どこかのアプリケーション サーバーを通過するのではなく、純粋に SQL で実行することでメリットが得られる、まれな大量のデータベース間の移行に使用しています。

ときどき行うだけで、Postgres 列挙型の番号は 100 ではなく 10 であるため、この回避策は、Postgres サーバーで移行を実行するパフォーマンス上の利点を維持するために実行できます。

于 2021-07-19T05:44:57.100 に答える