行レベルセキュリティ

テーブルごとに有効化し、読み取りを許す条件を USING、書き込みを許す条件を WITH CHECK でポリシーとして書く。条件はプランナーによってクエリに織り込まれるので、アプリのどこかで WHERE tenant_id = … を書き忘れても、データは漏れない。最も多いのはまさにそのマルチテナントの場面で、接続時に設定したセッション変数と行の所有者を比べるポリシーを使う。落とし穴は三つある。テーブル所有者は FORCE を指定しない限り自分のポリシーを素通りできること、ポリシーがオプティマイザの動きを制約して実行計画を悪化させ得ること、LEAKPROOF と印の付いていない関数が隠れた内容の推測に使われる可能性が理論上あることだ。