符号化方式の変換に失敗した時、再帰的なエラーによるクラッシュを防止しました。(Tom)

この変更は、最近の2つのマイナーリリースにて関連する失敗の状況に対してなされた改修を拡張したものです。 前回の修正は元の問題報告に特化したものでしたが、符号化方式変換関数で発生するすべてのエラーがそのエラーを報告しようとして、無限に再帰される可能性があることが分かりました。 したがって、再帰的なエラー報告を行う状況になったことがわかった時の解決策は、変換と符号化方式を無効にし、通常のASCII形式のエラーメッセージで報告することです。 (CVE-2009-0922)

特定の変換関数に対する、間違った符号化方式を用いたCREATE CONVERSIONを許可しません。(Heikki)

これにより、符号化方式に関する失敗における、あり得る状況を防止します。 前回の変更は、同じ問題における別の種類の失敗に対する防止策でした。

不要なパス表現の変更を行わないようにxpath()を修正しました。 また、必要な時により正しく試行するように修正しました。(Andrew)

標準SQLでは、 xpathは文書断片となるデータに対して動作しなければならないと提言していますが、 libxmlはこれをサポートしておらず、実際のところXpath標準に従って動作しているかどうか不明です。 xpathは、データとパス表現の両方を変更することでこの不適合を回避しようとしていました。 しかしこの変更に不具合があり、有効な検索が失敗することが発生する可能性がありました。 xpathは、整形式のXML文書かどうか検査し、そして、整形式の場合にデータやパス表現を変更せずにlibxmlを呼び出すようにしました。 さもなくば、失敗する可能性を少なくした別の変更方法が使用されます。

引数のデータに対して不適切な整形用のコードがto_char()に渡された時のコアダンプを修正しました。(Tom)

Cロケールがマルチバイト符号化方式で使用された場合の全文検索が失敗する可能性を修正しました。(Teodor)

wchar_tがintよりもビット数が小さい時にクラッシュする可能性がありました。 具体的にはWindowsです。

Eメールのような複数の@文字を含む文字列に対する、非常に非効率的な全文検索のパーサの扱いを修正しました。(Heikki)

大規模な副問い合わせの出力リストにおける副SELECTに関するプランナの問題を修正しました。(Tom)

このバグに関する既知の兆候は、含まれるデータ型に依存して発生する「failed to locate grouping columns」というエラーです。 しかし他の問題も発生していたかもしれません。

暗黙的な強制を使用したCASE WHENの逆コンパイルを修正しました。 (Tom)

この間違いにより、アサートを有効にして構築した場合にアサート失敗が発生する可能性がありました。 また、他の構築状況でもビューの検証やダンプを行う際に「unexpected CASE WHEN clause」というエラーメッセージが発生する可能性がありました。

TOASTテーブルの行型に対する所有者を間違って割り当てる可能性を修正しました。(Tom)

CLUSTERまたはALTER TABLEの書き換え構文がテーブル所有者以外のユーザにより実行された場合、テーブルのTOASTテーブル向けのpg_type項目が実行したユーザが所有するものとして記録されてしまいました。 TOASTの行型に対する権限は通常のデータベース操作ではまったく検証されませんので、これによりすぐに問題が発生することはありません。 しかし、後でコマンドを発行したロールを削除しようとした場合に想定外の失敗（8.1または8.2）や削除後にpg_dumpが「owner of data type appears to be invalid」という警告が発生する（8.3）可能性がありました。

現在のセッションがまったくLISTENコマンドを実行していない場合にUNLISTENがすぐに終了するように変更しました。(Tom)

ほとんどの状況では、これは特に有用な最適化ではありません。 しかし、DISCARD ALLはUNLISTENを呼び出しますので、これまでのコードでは、DISCARD ALLを非常に多く使用するアプリケーションでは、顕著な性能問題が発生していました。

PL/pgSQLが、INSERT後のINTOを文字列の起点だけではなく、任意の位置におけるINTO変数句として扱わないように修正しました。 具体的には、CREATE RULE内のINSERT INTOにて失敗しないようにしました。(Tom)

ブロックの終了時に、PL/pgSQLのエラー状態変数を完全に消去します。(Ashesh Vashi、Dave Page)

これはPL/pgSQL自体の問題ではありませんが、これを行わないと、PL/pgSQLデバッガが関数の状態を検証する際にクラッシュする可能性がありました。

WindowsにおいてCallNamedPipe()呼び出しが失敗した時に再試行します。(Steve Marshall、Magnus)

この関数は一時的に失敗することが時々あるようです。 これまでは重大なエラーとしてすべての失敗を扱っていましたが、LISTEN、NOTIFYやその他の操作が混乱する可能性がありました。

デフォルトの既知の時間帯省略形のリストにMUST（モーリシャス島夏時間）を追加しました。(Xavier Bugaud)