昨日、 Pavel StehuleはPostgreSQLのSQL / PSM手続き言語の実装作業を完了しました。
現時点では、言語は必要なものをすべてサポートしています。
- 単純なもの-配列、複合型（複合）、トリガー。
- 追加-テーブル、IN / OUTパラメータを返す関数。
- SQL / PSM機能-警告、例外ハンドラー（主にSQLCODEに基づく）、SIGNALおよびRESIGNALステートメント。
- DB2およびMySQLの一部の機能は、マルチ割り当てステートメントであり、マジック変数SQLSTATEおよびSQLCODEのサポートです。
いくつかの例：
関数test74_2の作成または置換（）
テキストを$$として返します
アトミックを開始
sqlstate '03000'のnot_found条件を宣言します。
not_foundの取り消しハンドラーを宣言します
始める
xx、yyテキストを宣言します。
スタック診断を取得xx = condition_identifier、yy = return_sqlstate;
return xx || 「信号処理」|| yy
終わり;
シグナルnot_found;
終わり;
$$言語psm0;
関数test66（int、out r int）を$$として作成または置換します
始める
sqlstate '01002'のcontinueハンドラを宣言します
set r = r + 1;
sqlstate '01003'の継続ハンドラを宣言します
set r = r + 2;
セットr = 0;
x：a> 0 do
a％2 = 0の場合
sqlstate '01002';
他に
sqlstate '01003';
終了する場合;
set a = a-1;
終了する;
終わり;
$$言語psm0;
この言語は、ネイティブPL / pgSQLの代替として開発されたものではありません。 少し異なる哲学を持つ代替言語として開発されました。
- コンパイル段階でのネストされたSQLの完全な検証。
- ネストされたSQL結果のターゲットタイプへの早期変換。
この言語の主な利点は、ネストされたSQL式の使用時のエラーを早期に検索できることです（通常はコンパイル段階で）。 この機能は非常に優れています。 PSMは非常に静的な言語です。 一方では、PL / pgSQLが使用された場合よりも、動的SQLクエリを操作するためにより多くのジェスチャーが必要です。 一方、PL / pgSQLを使用する場合の多くのランタイムエラーは、PSMを使用する場合のコンパイル時に検出できます。
タスクのリスト：
- 完全なコード分析、コメントの追加-ボランティアはいますか？
- パフォーマンスの最適化。
- エラーメッセージのデバッグ。
ソースコードはgithubで入手できます。 どんな助けも大歓迎です。