Source is document....で鬱。
2004年5月11日 コンピュータPostgreSQL は Stored Procedure に相当するものは
関数という形になっている。
テーブルの更新など処理を SELECT文から呼び出すのは
違和感を否めないが仕方がない。
(ど〜せおれはこんなものを使わなきゃいけない
くずエンジニアですよ。)
で、この関数、Overload させることができる。
・・・っていうより、引数の型の違う同名の関数を
CREATE OR REPLACE FUNCTION を使って定義すると
前のがそのまま残ってしまう。
完全に差し替えたい場合に
呼び出し側を変え忘れてしまっていた場合、
関数が存在しないことより
誤った関数を呼び出してしまうほうが
数段危険だとおもうのだが。。。
で、関数を削除するには、DROP FUNCTION で
関数名の他に型も指定しなければならない。
・・・関数名だけ指定すれば Overload している
全関数を削除してくれてもいい気もするが
Object指向的に使うことを考えると
そうもいかないか。まぁ仕方がない。
(さっきとは別の意味で。)
MS SQL Server の場合は
Stored Procedure に枝番を付けて
一括で削除になっているが。
で、一々消すのが面倒で、
どんどんごみ関数がたまってきました。
これを一括で削除する方法はないかと検討した。
PostgreSQL のシステムカタログの pg_proc に
関数の一覧がある。
public schema で登録していて OWNER が特定のユーザーの関数から
選択して DROP FUNCTION の SQL文を生成するようにしたい。
ここで、引数のデータ型のリストは proargtypes Field にあるのだが、
これが oid のリストである oidvector という
PostgreSQL のシステム用の型で表されている。
これを Decode しないと型がわからない。
でも、どうやって・・・?
information schema の方でやろうかとも思ったが、
こっちは OWNER の特定方法がよくわからない。
specific_name と pg_proc の列との結びつけ方もわからない。
で、この方法はあきらめた。
システムカタログの pg_type で oidvector を見てみたが、
これもいまいち役に立たない。
う〜ん、どうしたらいいんだ。。。
PSQL の \d で型の情報出せたかな・・・とか見ていて、
\df で関数の引数のリストが Decode された形で
でてくることに気がついた。
で、これはいったいどうやっているんだ・・・って
PostgreSQL のソースを検索することにする。
\df で表示されるときの Field名の「Argument data types」で
PSQL のソースを grepすると・・・describe.c が引っかかった。
該当場所を見ると、SQL文があり、
そのなかで「pg_catalog.oidvectortypes」という内部関数が使われていた。
これこそが求めていたもの!!
ちゅうわけで、MS Access のパススルークエリで
(pgAccess も使えないので ODBC 接続を利用して
MS Access を作業の Frontend に使っている。)
=================
SELECT proname，pg_catalog.oidvectortypes(proargtypes) AS proargtypenames
from pg_proc
where proowner=
(SELECT usesysid FROM pg_user where usename=’XXXX’) ORDER BY proname
=================
としてユーザー定義関数の一覧P_Func_Listを作成し、
これを利用して、Access で
=================
SELECT ’DROP FUNCTION ’ & [proname] & ’(’ & [proargtypenames] & ’);’ AS 式1
FROM P_Func_List
WHERE (((P_Func_List.proname) Not Like ’tg_*’));
=================
として削除したい関数に対する DROP FUNCTION文を作成した。
(前者の SQL は PostgreSQL， 後者のSQLが MS Access (JET)であることに注意。)
この出力をコピペして目的のリストはできあがった。
まぁ、結局、Source is document. ってところか。
でも、僕はこの言葉は好きでない・・・とか
またいろいろ余計なことを考えて鬱状態。
なんでこんな会社にいるんだろ。
はぁ。。。。
関数という形になっている。
テーブルの更新など処理を SELECT文から呼び出すのは
違和感を否めないが仕方がない。
(ど〜せおれはこんなものを使わなきゃいけない
くずエンジニアですよ。)
で、この関数、Overload させることができる。
・・・っていうより、引数の型の違う同名の関数を
CREATE OR REPLACE FUNCTION を使って定義すると
前のがそのまま残ってしまう。
完全に差し替えたい場合に
呼び出し側を変え忘れてしまっていた場合、
関数が存在しないことより
誤った関数を呼び出してしまうほうが
数段危険だとおもうのだが。。。
で、関数を削除するには、DROP FUNCTION で
関数名の他に型も指定しなければならない。
・・・関数名だけ指定すれば Overload している
全関数を削除してくれてもいい気もするが
Object指向的に使うことを考えると
そうもいかないか。まぁ仕方がない。
(さっきとは別の意味で。)
MS SQL Server の場合は
Stored Procedure に枝番を付けて
一括で削除になっているが。
で、一々消すのが面倒で、
どんどんごみ関数がたまってきました。
これを一括で削除する方法はないかと検討した。
PostgreSQL のシステムカタログの pg_proc に
関数の一覧がある。
public schema で登録していて OWNER が特定のユーザーの関数から
選択して DROP FUNCTION の SQL文を生成するようにしたい。
ここで、引数のデータ型のリストは proargtypes Field にあるのだが、
これが oid のリストである oidvector という
PostgreSQL のシステム用の型で表されている。
これを Decode しないと型がわからない。
でも、どうやって・・・?
information schema の方でやろうかとも思ったが、
こっちは OWNER の特定方法がよくわからない。
specific_name と pg_proc の列との結びつけ方もわからない。
で、この方法はあきらめた。
システムカタログの pg_type で oidvector を見てみたが、
これもいまいち役に立たない。
う〜ん、どうしたらいいんだ。。。
PSQL の \d で型の情報出せたかな・・・とか見ていて、
\df で関数の引数のリストが Decode された形で
でてくることに気がついた。
で、これはいったいどうやっているんだ・・・って
PostgreSQL のソースを検索することにする。
\df で表示されるときの Field名の「Argument data types」で
PSQL のソースを grepすると・・・describe.c が引っかかった。
該当場所を見ると、SQL文があり、
そのなかで「pg_catalog.oidvectortypes」という内部関数が使われていた。
これこそが求めていたもの!!
ちゅうわけで、MS Access のパススルークエリで
(pgAccess も使えないので ODBC 接続を利用して
MS Access を作業の Frontend に使っている。)
=================
SELECT proname，pg_catalog.oidvectortypes(proargtypes) AS proargtypenames
from pg_proc
where proowner=
(SELECT usesysid FROM pg_user where usename=’XXXX’) ORDER BY proname
=================
としてユーザー定義関数の一覧P_Func_Listを作成し、
これを利用して、Access で
=================
SELECT ’DROP FUNCTION ’ & [proname] & ’(’ & [proargtypenames] & ’);’ AS 式1
FROM P_Func_List
WHERE (((P_Func_List.proname) Not Like ’tg_*’));
=================
として削除したい関数に対する DROP FUNCTION文を作成した。
(前者の SQL は PostgreSQL， 後者のSQLが MS Access (JET)であることに注意。)
この出力をコピペして目的のリストはできあがった。
まぁ、結局、Source is document. ってところか。
でも、僕はこの言葉は好きでない・・・とか
またいろいろ余計なことを考えて鬱状態。
なんでこんな会社にいるんだろ。
はぁ。。。。
コメント