[pgsql-jp: 32140] Re: トランザクション中に ERRORが発生するとABORT する

[tamaki.]

加藤様。ご回答感謝いたします。

> え〜と、トランザクション処理なのですから、それが普通じゃないですか??
> # 実はサブジェクトを拝見した時、トランザクション処理中にErrorが発生す
> # るとPostgreSQLが落ちる!? のかと思ってしまいました ^^;;

確かに、タイトルを見るとそのようなショッキングな事件にも捉えられますね。
一応、後で見たときにわかりやすいようにと考慮したつもりだったのですが、
配慮が足りなかったみたいです。(汗


> 
> DBMSのトランザクション処理は、一連の処理が矛盾をきたすことなく、正しく
> 終了するための処理であり、矛盾には他者からの操作(参照/挿入/更新/削除)
> からデータを保護する役目もありますが、一連の処理=自分自身の操作に対し
> ても保護がかからないと意味がありません。誤ったまま処理を続けても矛盾が
> 広がるだけなのですから。例えば、カラム制約条件をつける場合など、トラン
> ザクション(＝一連の処理)の順序性を考えないと自身の処理中であっても矛盾
> が発生する事はあります。
> 
> そんなわけで、
> 
> 
>>　おそらく仕様上の動きなのでしょうが、
> 
> 
> DBMSのあるべき仕様であり、状態に応じた処理をしたいのであれば、仕様を理
> 解した上で自分で回避方法をたてるのが正しいかと思います。
> 

(以後プログラムでの実装を想定しています)

こちらのご指摘なのですが、確かに一連のSQLを野放図に投げっぱなしにした場合には、
DB上に矛盾した状態が出現してしまう懸念があり、正しいと思います。
ただ、個々のSQLに対してクライアント側で例外の発生を見張っていた場合、

例外発生！
a.当該レコードの内容を別ファイルに保管＆エラーメッセージをログに書き残して処理続行
(それ以降のデータに関しても同様の処理を行い最後にCommit)
b.エラーメッセージをログに書き残して処理中断(Rollback)

と言うように、例外の状況と仕様の用件にあわせて処理を分岐させられる可能性を残すこと
が出来るのに対して、

例外発生！
→即ABORT

では、プログラマが取れる対応策の範囲を否が応でも狭める結果になっていまい残念な事だ
と思いました。


> ・UNIQUE KEYを設定したカラム a がある
> ・カラム a に値を設定したい。
>   −新規値なら挿入
>   −既存値なら更新
> 
> とかしたいだけではないのですか?
> 

先の例に対しては対症療法として有効だと思いますが、決定的な解決策とは言えないのでは
無いでしょうか？

とか偉そうに言ってる暇があったら自分で直せばいいじゃん。とか言われそうですが。(^^;

玉置