ユーザは、関数とルールで、バックエンドサーバにプログラ ムを挿入することができ、他のユーザはそのことを知らないで実行すること ができます。従い、その両方の機構によって、ユーザはあまり咎められる ことも無く、トロイの木馬を仕掛けることができま す。本当の保護は関数(すなわち、SQLの場での関係への書き込み) とルールを定義できるユーザを厳しく制御することです。 pg_classやpg_userおよび pg_groupに対する、監査記録と警報機構を推奨します。
SQL 以外の言語で書かれた関数はバックエンドサーバ・プロ セスの中で、ユーザ postgres (バックエンドサー バが本当に有効な ユーザ-id を postgres に設 定する) の権限で走らせます。ユーザは、信用のおける関数の中 から、そのサーバの内部データ構造を変えることができます。そのため、その 他色々ある中で、このような関数はいかなるシステム制御も欺くこ とができます。これは、ユーザ定義によるC関数固有の問題です。
SQL 関数のように、いつもルールはバックエンドユーザを起 動したユーザの身元と許可で走ります。
Postgres の内側に暗号化されたデータを 明示的にサポートする計画はありません。(しかし、ユーザがユーザ定義関数 の中でデータを暗号化するのを妨げるものも全くありません)。暗号化された ネットワーク接続を明示的にサポートする計画も無く、フロントエンド/バッ クエンド・プロトコルの全体的な書き換えも未定です。
ユーザ名、グループ名、および、システムに関連した識別子(たとえば、 pg_user.usesysidの内容)は一つのデータベースの中では 一意であると仮定されます。もしそうでなければ、予想外の結果が起こるかも しれません。