Crypt戦記 〜天網恢恢編〜
2004年4月4日 コンピュータ少し前の話。
===================================================
Crypt を司る Windows用の ActiveX Object を作ったので、
登録処理などを Access からするのには困っていなかった。
(Crypt戦記復讐編 http://diarynote.jp/d/10395/20031108.html)
(Crypt戦記怨念編 http://diarynote.jp/d/10395/20031104.html)
しかし、システムの改善を図るにあたり、
やはり PostgreSQLで Crypt関数が必要になってきた。
しかし、まだ作っていないし、
UNIX の Cでの開発・テスト環境は僕の管理下にはない。
そういうわけで、PL/Perl を使えるよう
システム管理者(兼開発者)の人に依頼した。
そこで相談して、再コンパイルとかするならついでに
PostgreSQL 7.3.4 から PostgreSQL 7.4.2 に
Version Up しようということになった。
翌日の朝に切り替え作業を行うことにして。
管理者の人は開発環境ですでに PostgreSQL 7.4.2 を使っており、
システムが動くことは確認済みである。
でも、まぁ一応リリースノートに目を通しておくことにした。
7.4.2 は重要度が高そうな BUG Fix で、
7.4.1 は特に気にするところなし。
7.4.0 も・・・・あれ?
「Add md5() function to main server， already in contrib/pgcrypto」
おぉ、MD5 が使えるようになったのか・・・って
contrib/pgcrypto っていったい何?
この時点では管理者の人に雑談レベルで
「7.4 から MD5 が使えるようになっているらしい」って話をした。
が、contrib/pgcrypto を調べてみる。
Google って見たが、とくに有用な情報はない。
で、 PostgreSQL のソースを見る。
・・・contrib というディレクトリがあり、
そしてその中に pgcrypto というディレクトリもあった。
で、その中を見ると・・・
僕が望んでいた crypt関数が含まれていた。(爆)
うがぁ〜〜〜〜〜。前からほしかったのにぃ。
これがあるなら ActiveX Object なんて作る必要なかったのにぃ〜〜〜。
とりあえず、こんなんがあったことを伝え、
一緒にインストールしてくれと頼んだ。
うぐぐ・・・。
やはり、この程度のことを考えていないはずはなかった。
PostgreSQL の文化を理解していなかったのが敗因だな。
その後、管理者の人から PostgreSQL の今使っているのの
コンパイルオプションは PL/Perl を使うようになっていると言われた。
しかし、createlang では組み込めないのを示してさらに調べてもらった。
Perl の Version が合わず、
その部分に関してはコンパイルエラーが起こっていたことが後に判明し、
DB Server機の Perl の更新も行うことになった。
一方、さらについでで、pgAccess を使ってみたいから
PL/tcl も入れてと依頼したが、
tcl が DB Server機に入っておらず、
これはとりあえず見送ることになった。
翌日、インストールが完了した後、
Create Function でライブラリを組み込み、
試してみた。
無事、Windows上の Perl、Active X Object、
UNIX上での Perl、そして PostgreSQL の Crypt と同じ結果になった。
こうして Cryptの戦いは終わった。
==================================================
さて、さっそくこれを利用してシステムの改善・・・と
思ったらまた壁にぶつかった。
PL/pgSQL はエラー処理が出来ないのである。
(その後調べたが、PL/pgSQL に限らずどの言語でも Query中にエラーが起こると
そのまま関数のエラーとなり処理が戻ってしまう)
これじゃぁ PostgreSQL の外から処理を実行する必要がある。
DB内の処理を行うときは DBMS内で完結していないと使えない。
PHP を使った WEB からの指令と Access からの ODBC とで
別々に実装しなきゃいけないなんてばかげている。
DBMS に対する思想が足りないのか?
(もちろん、いずれは実装する・・・みたいな項目には挙がっているが)
そりゃ、WEB の Frontend Database としてのように単一システムなら
これでいいかも知れないが、
企業の基幹システムたりえることはないな。
独立性を持たせようとするなら Middle Were を用意しろとでもいうのか。
SOAPでも使えと?
うぅ・・・Oracle でも MS SQL Server でもいい。
IBM DB2 を使えというのなら勉強するから
俺にまともな DBMS をつかわせろ〜〜〜〜(血涙)
・・・転職先募集中・・・。
===================================================
Crypt を司る Windows用の ActiveX Object を作ったので、
登録処理などを Access からするのには困っていなかった。
(Crypt戦記復讐編 http://diarynote.jp/d/10395/20031108.html)
(Crypt戦記怨念編 http://diarynote.jp/d/10395/20031104.html)
しかし、システムの改善を図るにあたり、
やはり PostgreSQLで Crypt関数が必要になってきた。
しかし、まだ作っていないし、
UNIX の Cでの開発・テスト環境は僕の管理下にはない。
そういうわけで、PL/Perl を使えるよう
システム管理者(兼開発者)の人に依頼した。
そこで相談して、再コンパイルとかするならついでに
PostgreSQL 7.3.4 から PostgreSQL 7.4.2 に
Version Up しようということになった。
翌日の朝に切り替え作業を行うことにして。
管理者の人は開発環境ですでに PostgreSQL 7.4.2 を使っており、
システムが動くことは確認済みである。
でも、まぁ一応リリースノートに目を通しておくことにした。
7.4.2 は重要度が高そうな BUG Fix で、
7.4.1 は特に気にするところなし。
7.4.0 も・・・・あれ?
「Add md5() function to main server， already in contrib/pgcrypto」
おぉ、MD5 が使えるようになったのか・・・って
contrib/pgcrypto っていったい何?
この時点では管理者の人に雑談レベルで
「7.4 から MD5 が使えるようになっているらしい」って話をした。
が、contrib/pgcrypto を調べてみる。
Google って見たが、とくに有用な情報はない。
で、 PostgreSQL のソースを見る。
・・・contrib というディレクトリがあり、
そしてその中に pgcrypto というディレクトリもあった。
で、その中を見ると・・・
僕が望んでいた crypt関数が含まれていた。(爆)
うがぁ〜〜〜〜〜。前からほしかったのにぃ。
これがあるなら ActiveX Object なんて作る必要なかったのにぃ〜〜〜。
とりあえず、こんなんがあったことを伝え、
一緒にインストールしてくれと頼んだ。
うぐぐ・・・。
やはり、この程度のことを考えていないはずはなかった。
PostgreSQL の文化を理解していなかったのが敗因だな。
その後、管理者の人から PostgreSQL の今使っているのの
コンパイルオプションは PL/Perl を使うようになっていると言われた。
しかし、createlang では組み込めないのを示してさらに調べてもらった。
Perl の Version が合わず、
その部分に関してはコンパイルエラーが起こっていたことが後に判明し、
DB Server機の Perl の更新も行うことになった。
一方、さらについでで、pgAccess を使ってみたいから
PL/tcl も入れてと依頼したが、
tcl が DB Server機に入っておらず、
これはとりあえず見送ることになった。
翌日、インストールが完了した後、
Create Function でライブラリを組み込み、
試してみた。
無事、Windows上の Perl、Active X Object、
UNIX上での Perl、そして PostgreSQL の Crypt と同じ結果になった。
こうして Cryptの戦いは終わった。
==================================================
さて、さっそくこれを利用してシステムの改善・・・と
思ったらまた壁にぶつかった。
PL/pgSQL はエラー処理が出来ないのである。
(その後調べたが、PL/pgSQL に限らずどの言語でも Query中にエラーが起こると
そのまま関数のエラーとなり処理が戻ってしまう)
これじゃぁ PostgreSQL の外から処理を実行する必要がある。
DB内の処理を行うときは DBMS内で完結していないと使えない。
PHP を使った WEB からの指令と Access からの ODBC とで
別々に実装しなきゃいけないなんてばかげている。
DBMS に対する思想が足りないのか?
(もちろん、いずれは実装する・・・みたいな項目には挙がっているが)
そりゃ、WEB の Frontend Database としてのように単一システムなら
これでいいかも知れないが、
企業の基幹システムたりえることはないな。
独立性を持たせようとするなら Middle Were を用意しろとでもいうのか。
SOAPでも使えと?
うぅ・・・Oracle でも MS SQL Server でもいい。
IBM DB2 を使えというのなら勉強するから
俺にまともな DBMS をつかわせろ〜〜〜〜(血涙)
・・・転職先募集中・・・。
コメント