2

これが私のセットアップです。と の 2 つのスキーマがmy_appありstatic_dataます。後者は静的ダンプからインポートされます。アプリケーション ロジックのニーズに合わせて、 のテーブルを使用するビューを作成し、それらをスキーマstatic_dataに格納しました。my_app

それはすべてうまくいきます。static_dataしかし、スキーマを新しいダンプで更新し、ビューで新しいデータを使用する必要があります。問題は、私が何をしても、ビューが常に古いスキーマを参照することです!

新しいスキーマ に新しいダンプをインポートしてstatic_data_newから、削除static_dataして に名前static_data_newを変更しようとしましたstatic_data。ビューが のテーブルに依存しているため、これは機能しませんstatic_data。したがって、PostgreSQL では削除できません。

次に、に設定search_pathしてみましたstatic_data_new。しかし、私がそうすると、ビューはまだ古いテーブルを参照しています!

を使用してテーブルを参照するビューを持つことは可能search_pathですか? ありがとう。

4

1 に答える 1

3

ビューは、基礎となるオブジェクトにバインドされます。オブジェクトの名前を変更しても、このリンクには影響しません。あなたの問題に対処するには、
基本的に3つの異なる方法があります。

  1. DELETECREATE新しいテーブルを配置したら、ビューを再表示します。完全な作成スクリプトをまとめれば、すぐに簡単かつ高速に実行できます。権限のリセットも忘れずに。ただし、再作成スクリプトをコンパイルするのは面倒かもしれません。

  2. ビューの代わりにテーブル関数(関数RETURNING SETOF rowsまたは) を使用します。RETURNING TABLEこれにより、「遅延バインディング」が得られます。オブジェクト名は、作成時ではなく、実行時にシステム カタログで検索されます。それらのオブジェクトを実際に見つけることができるのはあなたの責任です。

    は関数ごとに事前設定search_pathできます。また、実行ロールの は、明示的にスキーマ修飾されていないオブジェクトに対して有効になります。SO に関するこの関連する回答の詳細な手順とリンク。search_path

    関数は基本的に準備済みステートメントに似ており、ビューとは微妙に異なる動作をします。dba.SE に関するこの関連する回答の詳細。

  3. andの代わりに、新しいデータのTRUNCATEandINSERTルートを使用します。その後、すべての参照はそのまま残ります。それについてのより詳細な回答はこちらをご覧ください。DELETECREATE

    外部キーがテーブルを参照する場合は、DELETE FROM TABLE代わりに使用するか、外部キー制約を削除して再作成する必要があります。参照整合性を復元できるかどうかはユーザーの責任です。そうしないと、外部キーの再作成が失敗します。

于 2012-05-12T01:05:48.320 に答える