postgreSQL8.3でto_timestamp等する時、キャストしないといけないんだ！

いま、昔のソースをWindows版のPostgreSQL 8.3で動かそうとしたんだけど、
to_timestampのところで、エラー・・・

function to_timestamp(date,unknown) does not exist

とかでるのよ。to_timestampがないわけないけど、型がunknown？？

と思って調べてみたら・・・
PostgreSQL 8.3 に関する技術情報
http://www.sraoss.co.jp/technology/postgresql/8.3/
（以下斜体は上記サイトより引用）


8.3 への移行
すべての過去のリリースからデータを移行する場合、pg_dump を使用したダンプ・リストアが必要です。

互換性のない変更点
一般
文字でない型 (日付型など) を自動的に text 型に変換しないようにしました。
今までは text 型入力を受けとる演算子や関数に文字でない値が渡されると、自動的に text 型にキャストしていました。 これからは text 型でないデータを渡したい場合には text 型への明示的なキャストが必要になります。


そして、キャストしないと・・・


これらの SQL は "function does not exist" や "operator does not exist" エラーになります。


げ、げげ・・・
to_timestampは、まさに、こいつだ・・・

つまり、たとえば、変数updayがdate型だったりしたら、upday::textって書かないといけない。

あちゃー・・・

もう、めげた・・・風邪引いてるのに・・・

ソフトバンクが描く驚天動地のシナリオ

ソフトバンク、すげー（＠＿＠！）。。。

ここの記事(記事の３ページ目）
官と民を震撼させた“転向劇”の内幕
ＮＴＴと手を組むソフトバンクの狙い
http://diamond.jp/series/it_biz_dw/10022/?page=3
（以下斜体は上記サイトより引用）

まず、

　現時点で、ソフトバンクは明言を避けているが、将来的には必ずＡＤＳＬ事業を切り離さざるをえなくなる時期がやって来る。

　それは、ＡＤＳＬの貸し手であるＮＴＴが、2010年度中に電話回線をどうするのか基本的な方針を表明しなければならないことになっているからだ。すでに、時代の趨勢はＦＴＴＨだが、「事業者との契約の関係で、ＮＴＴが電話回線を止めると決めた時点から4年後でないと、実際にはＦＴＴＨに置き換えることができない」（持ち株会社の幹部）。


そうな・・・へ、ＦＴＴＨになっちゃうの・・・
（次のページ）

ソフトバンクの目のつけどころは、ここにある。つまり、いくらＦＴＴＨが主流でも、ユニバーサルサービスがＤＮＡに染み付いているＮＴＴにとって、地方に住む電話だけで十分な高齢者などを切り捨てることはできない。ユーザーがいるうちは電話回線の完全撤廃に踏み切れず、2010年以降もＡＤＳＬは続く。

ウィリアムのいたずらは、自分では「お年寄りではない」とおもっているけど、
当分ＡＤＳＬのつもりというか、なんか、乗り換えたり、
めんどっちいことはしたくないなあ・・・


その間、ソフトバンクは、各種の新サービスを繰り出しつつ、日本のブロードバンド人口の約10％に当たる400万～500万人のＡＤＳＬユーザーの離脱を防ぎながら、ＩＳＰサービスと同時にＮＴＴの「フレッツ光」を売りまくって手数料を稼ぐ。


ほお・・・

　そうすれば、06年に孫社長がブチ上げたものの、実際には進展していない自前のアクセス系光通信計画への株主からの批判をかわすことができるし、多額の設備投資もしないですむ。


なろほど・・・


ソフトバンクが本気でＦＴＴＨを売りまくれば、08年9月時点で約73％のＮＴＴのシェアは90％を超えてしまうはず。となると、ＮＴＴは、電話局から家庭までをつなぐアクセス系光通信で、意図せずして、再び独占に向かう。

　そうなれば、ソフトバンクが事を荒立てなくても、世間の批判はＮＴＴに集中する。


あちゃー・・・


そして、技術の世代交代を見計らって、自社のユーザーを失わずに、ＡＤＳＬからＦＴＴＨに乗り換える――。


たしかに、ウィリアムのいたずらもＹＡＨＯＯ　ＢＢだけど、もし、ＹＡＨＯＯ　ＢＢのＡＤＳＬサービスが終わったら、乗り換えるもんなあ・・・


なんか、また、孫社長の高笑いですか・・・？？

バザール型ＥＡ

　従来のＥＡっていうのは、会社全体のシステムを調査し(to-be)、そしてあるべき姿を分析する(as-if)という形式だった。つまり、全体像を描き挙げ、それを、ブレークダウンし、実装していくという、

伽藍とバザール
http://cruel.org/freeware/cathedral.html

で言えば、伽藍型の開発方法といえる。

---

　では、バザール型の開発方法はないのか？

　つまり、会社の機能を部分部分につくっていき、それをつなぎ合わせる手法

・・・って、まさにＳＯＡである（＾＾；）

　でも、その場合、各部分で利用するデータの関連をとるには、どーしたらいいだろう？

　従来（伽藍型）は、会社全体を考え、そこからデータの全体構造、関連を正規化手法にしてＥＲ図などで表現し、１事実１箇所、データベースによる関係演算で実現してきた。

　バザール型では、この全体構造をつかめない。プロジェクトが違えば、関連が分からないし、かりに分かったとしても、共通の表現方法を持たなければ、データを利活用できない。

　つまり、全体構造を把握して正規化するようなことを行わないで、データを関連付けれないといけない。

---

　っておもったら、それに対して、ヒントを言っていた人がいた。
　ＸＭＬコンソーシアムＤａｙのXMLDB部会の人の発表で、
　その部会ではゲストを呼んで、いろいろ聞くんだそうだが、
　アメリカのカーナビにＸＭＬＤＢを入れようとしている人が、

　ＸＭＬＤＢだと、正規化がいらないから・・・

　という言い方をしていた。

　たしかに、今はスピード的に問題あるけど、

　ＸＭＬＤＢだと、正規化しないで入れて、データに関連があれば、XLinkなどで、関連付けるという手もあるかもしれない。

---

　つーか、データの読み込み、書き出し、管理もＳＯＡで提供するようにして、そのサービスのひとつとして、データの関連性、正規化などのサポートをする、データディクショナリ＋管理支援サービスがあれば、ＸＭＬだろうがＲＤＢだろうが、関係ないか・・・

P.S 今日の夕方か、あしたあたりに、この辺の話のたとえ話として、

　スーパー（＝伽藍）とバザール

ってのを載せたいと思います。