通常、PL/Perlはplperlという名前で"信頼された"プログラミング言語としてインストールされます。 この設定では、セキュリティを確保するためにPerlの特定の操作は無効にされます。 一般的には、制限される操作は環境に作用するものです。 これには、ファイルハンドル操作やrequire、use（外部モジュール用）が含まれます。 C関数では可能ですが、Perlでは、データベースサーバ内部にアクセスする方法や、サーバプロセスの権限によるOSレベルのアクセスを行う方法はありません。 この結果、データベースの全ての非特権ユーザはこの言語を使用することができます。
セキュリティ上の理由により許されていないファイルシステム操作を行うため、うまく動作しない関数の例を以下に示します。
CREATE FUNCTION badfunc() RETURNS integer AS $$
my $tmpfile = "/tmp/badfile";
open my $fh, '>', $tmpfile
or elog(ERROR, qq{could not open the file "$tmpfile": $!});
print $fh "Testing writing to a file\n";
close $fh or elog(ERROR, qq{could not close the file "$tmpfile": $!});
return 1;
$$ LANGUAGE plperl;許されていない操作の使用が検証機能によって検出されますので、この関数の作成は失敗します。
制限のないPerl関数の作成が望ましい場合があります。 例えば、Perl 関数を使用してメールを送信するような場合です。 このような場合を扱うために、PL/Perlを"信頼されない"言語（通常PL/PerlUと呼ばれます）としてインストールすることもできます。 この場合は完全なPerl言語を使用することができます。 createlangプログラムが言語のインストールに使用された場合、plperluという言語名によって、信頼されないPL/Perlの亜種が選択されます。
PL/PerlU関数の作成者は、その関数を不必要なことに使用できないように注意する必要があります。 この関数は、データベース管理者としてログインしたユーザが実行できることを全て実行できるからです。 データベースシステムはデータベースのスーパーユーザにのみ信頼されない言語による関数作成を許可していることに注意してください。
上記の関数が、スーパーユーザによってplperlu言語を使用して作成された場合、実行は可能となります。
注意: PL/PerlUからPL/Perlへの特権操作の流出を防ぐというセキュリティ上の理由により、これらの2つの言語を別のPerlインタプリタのインスタンスで実行しなければなりません。 使用しているPerlのインストレーションが適切にコンパイルされていれば、問題にはなりません。 しかし、すべてのインストレーションが適切なフラグを付けてコンパイルされているとは限りません。 PostgreSQLがこの問題に該当することを検出すると、2つ目のインタプリタを起動せず、エラーを発生します。 このため、こうしたインストレーションでは、同一のバックエンドプロセス内でPL/PerlUとPL/Perlの両方を使用することはできません。 この問題の解消方法は、適切なフラグ、usemultiplicityまたは、usethreads及びuseithreadsの両方を付けてコンパイルしたPerlインストレーションを入手することです。 詳細はperlembedマニュアルページを参照してください。