Version 1.3.157 (2011-06-25)
タイムゾーンとか難しいよなあとか。
- CREATE TABLE ... AS SELECT ...のシンタックスの変更: NOT
PERSISTENTのようなオプションは、AS SELECTの前に置くようになった。そうでないと、オプションがAS
SELECT以下と解釈されてしまうため。
-
- ここで言っているオプションは、ENGINE,NOT PERSISTENT,TRANSACTIONALの3つ。具体的には、前までは、
CREATE TABLE HOGE AS SELECT * FROM FUGA NOT PERSISTENT
-
- だったのが
CREATE TABLE HOGE NOT PERSISTENT AS SELECT * FROM FUGA
-
- となった。まぁ、そりゃそうですね。
- バージョン1.3.156で、DB2モードではCLOB/BLOBが使えなかった。
- 1.3.156以前から、1.3.156へデータベースをアップグレードした場合に、CLOBやBLOBのデータが多くの場合ロストしていた
- null不可のカラムに対するCOUNT(..)の最適化もCOUNT(DISITINCT ..)となっていた。これは不正確である。
- 原文の意図からは大きくは外れてはいないと思うのだけれど。
- h2は、select count(*) from hogeというSQLの場合、実際の行をカウントせず、テーブル情報に記載されている行数をそのまま返すので、とても速い。
- select count(xxx) from hoge で、xxxカラムがnot nullの場合、select count(*) from hogeに最適化できる。
- ここまでは良かったが、select count(distinct xxx) from hoge も同様の最適化を行ってしまっていた、という問題っぽい。
- 原文の意図からは大きくは外れてはいないと思うのだけれど。
- PgServer: 非アドミンユーザがデータベースをオープンできなかった。
- 既にデータベースがオープンしている場合、(モードが一致している場合であっても)非アドミンユーザーがモードを指定して(MODE=xxx)データベースをオープンする事が出来なかった
- 次の例外のSQLステートが変更になった。90009, 90010, 90011 から22007に。"DATE/TIME/TIMESTAMP 定数 を解析できません"
- サマータイムのルールが異なるタイムゾーンでデータベースファイルを開く際の問題:サマータイムのルールが異なると日時のうち時刻部分が異なる。これは同じルールで地域が異なる場合には問題にならず、さらにタイムゾーンが異なっていても問題にならない。回避方法は、データベースを元のタイムゾーンでSQLスクリプトとしてエクスポートして、新しいタイムゾーンで新しいデータベースを作る事。同様の問題が、TCP/IP越しでクライアントとサーバーが異なるルールを使っている場合についても発生する。