私はPostgresデータの読み書きを厳密に制御する必要があります。更新可能なビューは、常にデータの読み取りを非常に良く厳密に制御し、貴重な計算カラムを追加することができます。 Postgres 9.5では、行レベルのセキュリティにより、データを制御するための新しく強力な方法が導入されました。しかし、テクノロジービューと行レベルのセキュリティを併用することはできません。どうして？Postgresビューで行レベルのセキュリティが有効になっていないのはなぜですか？
基本的に、ビューの動作を遡及的に変更できなかったためです。ビューのためにSECURITY INVOKER（または同等のもの）をサポートできるようにしたいと思いますが、私が知っている限り、そのような機能は現在存在しません。
ビューへのアクセスを、通常はセルフローのセキュリティでフィルタリングできます。
ビューによってアクセスされる表には、行セキュリティー・ルールも適用されます。ただし、current_userはビュー作成者と表示されます。ビューは、ビューを作成または所有するユーザーの権限でテーブルおよびその他のビューにアクセスするためです。
必要な機能やpgsql-generalの開発に踏み込んで助けてくれるのであれば、これをpgsql-hackersで行う価値はあるでしょうか？
ビューは作成中のユーザーとしてテーブルにアクセスし、それに応じてcurrent_userを変更しますが、行セキュリティポリシーでカスタムGUC、session_user、またはその他のコンテキスト情報を使用することはできません。行セキュリティをビューで使用することはできますが、current_userに基づいてフィルタリングする（有益には）わけではありません。
ビューの仕組みはどのように変化しますか？基本的にRLSではいくつかの「WHERE」条項が追加されただけではありませんか？そして基本的にSQLステートメントだけのビューではありませんか？ – Calebmer
@Calebmerビューは、ビューを作成したユーザーのアクセス権でビューが使用するテーブルにアクセスします。ビューにアクセスした "トップレベル"のユーザに基づくビューを介してアクセスされるテーブルへのアクセスを、行セキュリティがビューにアクセスする方法を変更する必要があるようにするには、 'current_user'が設定されていないようにします。 'session_user'ですが、これは' SET SESSION AUTHORIZATION'時に変更されないので、pgbouncerなどでプールされた接続を使用している場合は役に立ちません。 –
うわー..これは本当にポリシーのドキュメントページに言及する必要があります。私は、すべてのテーブルがプライベート・スキーマ内にあり、別のスキーマのビューを介して外部APIで使用できるようになっているアプリケーションでこの問題を発見しました。このビューはスーパーユーザーによって作成されたため、RLSはテストされていても実際のテーブルに対して正常に動作していても完全に破損していました。 – deinspanjer
テーブルで行レベルのセキュリティを有効にしてから、テーブルの更新可能なビューを使用すると、セキュリティは機能しませんか？ – mehmet
いいえ、問合せは現在のロールではなく、ビュー定義のロールを通過するためです。 – Calebmer
次に、ビュー定義ロールで行レベルのセキュリティを設定する方法はありますか。 – mehmet