ジャイアンじゃいや〜ん

PLPGSQLのストアドプロシージャが前まで動いていたんだけど、PostgreSQLのバージョンが変わったためか動かなくなった。

ERROR:  列参照 "hoge" が一意に特定できません
中略
DETAIL:  PL/pgSQL 変数もしくはテーブルのカラム名のどちらかを参照していた可能性があります。

という感じで、ストアドプロシージャの引数がそのままで使えないみたいだ。それまで特定できていた変数がどの変数だかわかんなくなっている感じ？　他のhogeとバッティングしているかと思っていたんだけど、それよりもそのストアドプロシージャのパラメータであることを示してあげないといけなかった。

CREATE OR REPLACE FUNCTION public.func_01(hoge text)

とかで中身でhogeがそのまま使えるはずだったんだが、PostgreSQL12では使えなくなっていた。参照する際にfunc_01.hoge みたいにしないといけなかった。他のものだとなしでもできていたので、public指定が悪さをしていたのかもしれない。

https://www.postgresql.jp/document/9.3/html/plpgsql-implementation.html

大体のことは上に書いてあった。こういうの地道に見つけるのしんどいなぁ。日本語とはいえ、エラーメッセージがすんなり出てきてくれたわけでもないし。


普通は引数をそのまま使える。実際、下のリンクのソースを張り付けて実行したら、動作したので今回はレアケースなのかもしれない。

https://db.just4fun.biz/?PL/pgSQL/%E5%BC%95%E6%95%B0%E3%82%92%E6%B8%A1%E3%81%99%E6%96%B9%E6%B3%95

psql -c で引数を渡せて、コマンドラインで実行できるのが一番の収穫だったかもしれない。それまでデバッグはおろか実行させるのも重いシステムごと動かしていたので、効率が超悪かったんですよね。Oracleとかだとステップ実行とかデバッグできるみたいなのだけれど、PostgreSQLはそこまでできないんですよね。へぼ互換ｗ。


あとストアドプロシージャの引数の名前が、その中で使えるのはPL/PGSQLぐらいみたいなので、一般的に使えるようにしたいなら

hoge ALIAS FOR $1;

みたいに数で入れ込むのがセオリーっぽい。あんまり引数が多くないなら、それでいいのかもしれないけど、できれば引数の名前でそのまま参照できた方がいいよね。とはいえ、なかなかSQLってのは独特な世界ではあるから、それを拡張したものとなると余計に標準から離れるのは面倒な話になりそうではある。