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

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

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

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

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

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

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

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

暗黙的な強制を使用した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）可能性がありました。

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)