７年連続２００本安打達成も道半ば
今日のヤンキース戦で今シーズンの２００安打目を放ち７年連続の２００安打を達成、近代野球（２０世紀以後）ではWade Boggsとならぶ偉業である。これに３０盗塁（更には１００得点）を組み合わせれば色々な歴代一位がでてくるのだが、詳しくは１００得点達成後（現在９８得点）にまとめる予定。
これほどの記録を続けているイチローではあるがメジャーでの殿堂入りは簡単ではあるまい。よく殿堂入り確実などと書かれているが根拠は乏しい。日本での成績を加味してくれればそう遠くはない目標であろうが、どうもそのあたりはあまり期待できなさそうである。イチローにとってもっとも確実な道はメジャーで３０００本安打を達成することである。ただしこの数字、今のハイペースを維持し続けても後７年もかかり（その時イチローは４０才）、イチローにとっても容易でないのは明らかだろう。どんなスーパースターでも長い年月をかけて実績を積み重ねていくことでしか達成できないからこそ殿堂入りが素晴らしいともいえる。現在イチローはメジャー通算１５５５安打、道半ばである。
由布姫パート
大河ドラマ「風林火山」も中盤に差し掛かってきた。ここ数話いわゆる由布姫パートが続いており、世間の評価も分かれているようである。姫はもういいよ、合戦まだぁ〜の人達も少なくないようだ。しかし今年の大河は「山本勘助」ではない。「風林火山」である以上、由布姫パートは物語の肝であり外すことはありえないし、中途半端は許されない。正直かなりの難題に、今大河はチャレンジしているのである。
由布姫パートを見る際には理屈とか善悪とかを気にしてはならない。
「消えた姫」回では、侍女のマキを死なせてしまったことが由布姫の評判をかなり落としているようだ。確かにマキは可哀そうだがマキは運が悪かったのだ。勿論マキの命は由布姫の命よりも軽い。由布姫が救われることでマキの犠牲は報われるしマキも手厚く供養されることだろう。人命が地球より重い現代日本とは違うのだ。
姫は我侭だし今後も他人に迷惑をかけ続けることだろうが、それが何だというのだろう。「他人に迷惑をかけない」というのは現代日本における最上の美徳だろうけれど、古今東西とりわけて普遍的な美徳とは思えない。そもそも「風林火山」は修身の教科書などではないのだし。
8.2.0402 コネクション数制限の撤廃
コネクションの数が１２８を超えると接続できなくなるとの報告あり。見てみると確かに１２８個のグローバル配列がありそれが原因である。この際でもあり、固定配列をやめて動的にテーブルを割り当てる方式に変えて制限を撤廃した。ただ報告者は最低でも２０４８といっており、トータルな資源消費でひっかかる可能性は残っている。
ルールシステムはこのままでよいのだろうか？
PostgreSQLではVIEWの仕組をRULEシステムをベースに構築しており、更にこれを利用して更新可能なVIEWも作成が可能となっている。しかし更新可能な
virtual tableとしてVIEWを見たときいささか心許ないものがある。実際私は更新可能なVIEWを使う気になれない。ということでわかっている問題点の覚書き。
RULEがマクロに過ぎないことによる副作用の発生が基本的な問題
- 引数の多重評価の発生 FAQ的な問題がある http://archives.postgresql.org/pgsql-sql/2003-07/msg00333.phpはその一例
- JOINビュー更新の不具合
- 例えば http://archives.postgresql.org/pgsql-odbc/2006-12/msg00029.php この場合実際は中途半端な部分更新が行われるのだが、更新は何もおこなわれなかったかのような報告がされる。結構深刻な問題である。
- ビュー更新の際のロックのタイミング違い？の問題（[pgsql-jp: 38295] SYNONYM 代わりのVIEW＋RULEへの、更新時ロックの挙動について）
- ロックのタイミングの違いとは少し違うようだ。RULEに従って変形していく時に発生する update .. from .. のPostgreSQL独自の構文においてfromで指定されるテーブルはread-onlyであって、それらには行ロックが取得されない。うーん、これはバグか仕様なのか？
8.2.0402 別のテスト
uniqueidentifier(http://gborg.postgresql.org/project/uniqueidentifier/projdisplay.php) というユーザー定義型を使用するとODBC経由のデータ読み込みで切捨てが発生するというバグレポートあり。URLを見てみたが古いプロジェクトだしWindows適用は不可みたいである。要は128ビット（=１６バイト）のUUIDを処理するためのものらしく、テキスト表示するととても１６文字では収まらない所が特徴のようだ。出来合の型で似たようなのはないかと探して見るとmacaddrという型が見つかったので、早速テストしてみたが確かに６文字でちょん切られてしまう。６という数字はmacaddrという型のバイナリ表現に必要なオクテット(=バイト）数でありユーザー定義型項目に対する問い合わせのこの数値を報告している箇所が見つかりました。それならテキスト表現に必要な大きさは？というと適切な方法が見当たらない。ということでユーザー定義型（というかpsqlodbcが意識しない型）に対しては最大長を答えるように変更を行いました。
8.2.0402 テスト中確認待ち
- いのっち父の雑談部屋にバグレポートあり、VB.NETのTableAdapterを使用するとUnicodeドライバではvarchar項目の最大長が半分になってしまうとのこと。バッファ長を文字数で返している箇所がありこれが原因かもしれない。ANSIバージョンだとOKらしいが、この項目は文字数でなくバイト数を返す項目なので、逆にマルチバイト項目を定義された文字数まで処理できるかどうかが少し心配になる。
- @@iDENTITYの処理を元に戻した。Microsoftのアプリには@@IDENTITY参照を行うものがある。代表的なアプリはAccessであり、オートナンバー型項目の処理にこれを使っている。PostgreSQLでいうとシリアル型がこれに近い存在で、Accessからの問い合わせに色々工夫して答えるとオートナンバー型として認識されるようになる。さてバーション8.1でlastval()という関数が実装されこれがぴったり@@IDENTITYと対応するように思われたため、バージョン8.1以後のサーバーではlastval()を呼び出すように改良？したのだがやっぱりまずいという報告がきていたのである。動作はMicrosoft SQL Serverと同じようなので仕様通りなわけだが結果がまずいというのは何となくわかる。lastval()はそのセション内の最新のsequence更新値を拾ってくるのだが、sequenceであれば何でも対象になるのでトリガー内でついでに更新されたsequence値まで拾ってきてしまうのが望まぬ結果を招いてしまうのだろう。lastval()を使用しない実装ではINSERTの実行に一々割り込みをかけて対象テーブル（それについているsequence）を特定しているのでトリガによる誤？動作を避けることが出来ていたのでありました。
