GRANT 異なるオブジェクトのは別々です。 GRANT データベースでの実行はGRANTではありません 内のスキーマに対する権限。同様に、GRANT スキーマを使用しても、内のテーブルに対する権限は付与されません。
SELECTの権限がある場合 テーブルからですが、それを含むスキーマでそれを表示する権利はありません。その場合、テーブルにアクセスできません。
権利テストは次の順序で実行されます：
Do you have `USAGE` on the schema?
No: Reject access.
Yes: Do you also have the appropriate rights on the table?
No: Reject access.
Yes: Check column privileges.
publicという事実から、混乱が生じる可能性があります。 スキーマにはデフォルトのGRANTがあります 役割publicに対するすべての権利の 、すべてのユーザー/グループがメンバーになっています。したがって、誰もがすでにそのスキーマを使用しています。
フレーズ：
（オブジェクト自体の特権要件も満たされていると仮定します）
USAGEが必要だと言っています スキーマ内のオブジェクトを使用するためにスキーマ上にありますが、USAGEがあります スキーマ上では、それ自体ではスキーマ内のオブジェクトを使用するのに十分ではありません。オブジェクト自体に対する権限も必要です。
それはディレクトリツリーのようなものです。ディレクトリを作成する場合somedir ファイルsomefile その中で、自分のユーザーだけがディレクトリまたはファイルにアクセスできるように設定します（モードrwx------ ディレクトリで、モードrw------- ファイル上）の場合、他の誰もディレクトリをリストして、ファイルが存在することを確認できません。
ファイルに対してワールド読み取り権限を付与する場合（モードrw-r--r-- ）ただし、ディレクトリのアクセス許可は変更しないでください。違いはありません。誰も見ることができませんでした ディレクトリを一覧表示する権限がないため、ファイルを読み取るためにファイルを作成します。
代わりにrwx-r-xr-xを設定した場合 ディレクトリ上で、ユーザーがディレクトリを一覧表示してトラバースできるように設定しますが、ファイルのアクセス許可は変更しないでください。一覧表示 ファイルは読み取ることができませんでした ファイルにアクセスできないためです。
両方を設定する必要があります 人々が実際にファイルを表示できるようにするための権限。
Pgでも同じです。両方のスキーマUSAGEが必要です SELECTなどのオブジェクトに対してアクションを実行するための権限とオブジェクト権限 テーブルから。
（PostgreSQLにはまだ行レベルのセキュリティがないため、ユーザーはSELECTを使用して、テーブルがスキーマに存在することを「確認」できます。 pg_classからのing 直接。ただし、どのような方法でも相互作用することはできないため、まったく同じではないのは「リスト」の部分にすぎません。）