PostgreSQL手続き言語-PL / pgSQLとSQLの違い

誰でも次の違いを要約してください：

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

そして

http://www.postgresql.org/docs/9.1/static/plpgsql.html

？

主なポイント：

概念的な違い
問題の家族、与えられた便利さを考えると
政治的な問題

postgresql stored-procedures plpgsql

— ギズモラナス
ソース

第一に、SQL（別名クエリ言語）関数は、PostgreSQLの手続き言語を一切含みません。第二に、あなたはすでにあなたの質問に対する答えを見つけることができる最高のソースを見つけました（最後の質問を除いて-「政治問題」とは正確に何を意味しますか？）

— dezso

私が貼り付けたドキュメントを必ずしも使用せず、個人的な印象を使用して、すべての主要な問題を要約するよう求めました。これらのリンクは、質問が何であるかをすべての人が確実に理解できるようにするためのものです。

— ギズモラナス

それを暴行として受け取らないでください、しかし、それらを読んだら、あなたはそれをあなた自身で要約することができます:)そうでなければ、あなたの質問は少し広範ですが、少し時間を考えて、いくつかの考えを集めようとします。

— -dezso

他の手続き言語を無視しないでください。特に、PL / Perlは、PL / PgSQLが制限されすぎる分野で非常に役立ちます。あなたがPythonを好むならPL / Pythonuは仕事をしますが、PL / Perlのようなセキュリティモデルを提供しません。アドオンとしてPL / V8（JavaScript）もあります。

— クレイグリンガー

こんにちはcataldo-最初の質問はここにあるので、このサイトにようこそ。投稿していただき、ありがとうございます。

— ジャックダグラス

回答:

PL / PgSQLおよびプレーンSQL関数はどちらもより大きなツールセットの一部であり、そのコンテキストで表示する必要があります。私は、昇順の複雑さとコストが一致する昇順のパワーの観点からそれを考える傾向があります。そこでは、仕事をうまくやる最も簡単なツールを使用する必要があります。

可能な限りビューを使用する
ビューが適切でない場合は、SQL関数を使用します
SQL関数が適切でない場合は、PL / PgSQLを使用します。
PL / PgSQLが制限されすぎているか、表現力が不十分な場合は、PL / Perl、PL / Python、PL / V8、PL / Java、または好みのものを使用してください
...そして、PLが仕事をしない場合は、外部プログラムを使用し、場合によってはLISTENそれNOTIFYと話します。

機能が必要だと思う場合、ビューで十分であることが非常に多くあります。SELECTビュー全体に非常に負荷がかかる場合でも、WHERE通常、ビューを参照するクエリ内の句はビューにプッシュダウンされるため、クエリプランが大きく異なる可能性があります。SQL関数をビューに変換することで、パフォーマンスが大幅に向上することがよくあります。

ビューを使用できず、SQL関数を考慮する必要があるのは、主に次の場合です。

式内のWHEREパラメーターのように、単純な句として表現できないパラメーターが必要ですWITH
SECURITY DEFINER関数を介したセキュリティバリアが必要であり、security_barrierPostgreSQL 9.2以降のビューではニーズに十分ではありません。
オプティマイザーによってビューのサブ句にプッシュダウンされず、より直接制御したいパラメーターが必要です。または
パラメーターがたくさんあるか、パラメーターの繰り返しがたくさんあるので、クエリをビューとして書くのは実用的ではありません。

これらのタスクのほとんどでは、単純なSQL関数は正常に機能し、多くの場合、PL / PgSQLよりも読みやすくなっています。宣言された（STABLEまたは宣言されてIMMUTABLEいない、STRICTまたはSECURITY DEFINER）SQL関数は、呼び出しステートメントにインライン化することもできます。これにより、関数呼び出しのオーバーヘッドが取り除かれ、オプティマイザーによって呼び出し関数のWHERE条件がSQL関数にプッシュダウンされると、パフォーマンスが大幅に向上することもあります。タスクに十分なSQL関数を使用します。

SQL関数が仕事をしない主な時間は、多くのロジックが必要なときです。CASEステートメント、表現された結果の多くの再利用、チャンクからの値の構築、エラー処理などとして表現できないif / then / else操作。PL/ PgSQLが役立ちます。SQL関数を使用できない場合、または以下のように適合度が低い場合は、PL / PgSQLを選択します。

EXECUTEステートメントを介した動的SQLおよび動的DDL
あなたはしたい場合はRAISE、ログやクライアントのエラー/警告
例外処理が必要な場合- EXCEPTIONトランザクション全体をエラーで終了させる代わりに、ブロックでエラーをトラップして処理できます
CASE ... WHENうまく適合しない複雑な条件付きロジック
適合できない計算値WITHとCTE の再利用が多い
ダイナミックレコードの構築
結果セットを作成した後にアクションを実行する必要があります

共通テーブル式（CTE）、特に書き込み可能なCTE WITH RECURSIVEを使用すると、SQLが非常に表現力があり強力であるため、PL / PgSQLの使用が以前よりもはるかに少なくなっています。現在、ビューとプレーンSQL関数を使用しています。単純なSQL関数には複数のステートメントを含めることができることを思い出してください。最後のステートメントは、関数の結果です。

— クレイグリンガー
ソース

非常によく言いました！（書き込み可能なCTEに言及するための追加の仮想+1）

— -dezso

これは、一部の機能が最適化フェンスを必要とする理由も説明しています。

— エオニル

plpgsqlは、変数、ループ構造などを備えた本格的な手続き型言語SQLです。関数は、単なるサブクエリです。SQL関数は、宣言されているSTABLE場合IMMUTABLEでも宣言されていない場合でもSTRICT、多くの場合、各参照に書き込まれたかのように呼び出し元クエリにインライン化できます。

— kgrittn
ソース