当编码转换失败的时候，避免错误递归崩溃(Tom)

该变化为相关错误情况在最后两个次要版本中扩展修复。 之前修复程序为最初问题报告进行了细化， 但我们现在已经认识到通过编码转换函数抛出的任何错误 可能潜在地导致无限递归，而试图报告错误。 如果我们发现已经卷入了一个递归错误报告的情况时， 解决的办法是禁用转换以及编码转换并报告任何纯ASCII格式错误消息。

不允许为指定转换函数带有错误编码的CREATE CONVERSION(Heikki)

这可以防止编码转换失败的情况。之前变化是预防同一区域其它类型错误的手段。

修复xpath()不会修改路径表达式除非必要，并且当必要时做出理智尝试(Andrew)

SQL标准表明xpath致力于数据是一个文档片段， 但libxml不支持这一点， 其实这是不明确的，按照XPath标准是明智的。 xpath试图通过修改数据和路径表达式解决这个错误匹配， 但是修改是古怪的，并可能导致有效的搜索失败。现在， xpath检查数据是否实际上是一个良好的文档， 并且如果是这样调用不改变数据或路径表达式的libxml。 否则，一个不太可能失败的不同修改方法被使用。

当to_char()指定格式代码对于数据参数类型不合适的时候，修复核心转储(Tom)

当C语言环境用于多字节编码的时候，修复文本搜索中可能失败(Teodor)

在平台上有可能崩溃，即wchar_t比int更窄的时候，尤其Windows上。

修复文本搜索解析器的处理类似电子邮件包含多个@字符串效率低下的情况(Heikki)

修复较大子查询输出列表中子SELECT规划器问题(Tom)

这个错误已知现象是“未能定位分组列”依赖于涉及的数据类型错误； 但是也有可能是其它问题。

修复隐式强制CASE WHEN的反编译(Tom)

当尝试检查或者备份视图的时候，这个错误可能导致断言启动编译中断言错误，或者是其它情况中 “意外的CASE WHEN 子句”错误消息。

修复TOAST表的行类型拥有者可能错误分配(Tom)

如果CLUSTER或者ALTER TABLE的重写形式通过某人而不是表的所有者被执行， pg_type项为表的TOAST表将最终标记为由别人所拥有。 这没有造成直接的问题， 因为普通的数据库操作不会检查TOAST rowtype的权限。 然而，它可能会导致意外故障，如果之后尝试删除发出该命令的角色（在8.1或者8.2中）， 或者已经这样做之后（在8.3中）来自pg_dump中的“数据类型所有者似乎无效”警告。

如果当前会话从来没有执行任何LISTEN命令，那么改变UNLISTEN迅速退出(Tom)

多数情况下这不是一个特别有用的优化， 但因为DISCARD ALL调用UNLISTEN， 之前编码导致为大量使用DISCARD ALL的应用程序带来巨大的性能问题。

修复PL/pgSQL没有把INTO在INSERT之后看作字符串任意位置的一个INTO变量子句， 不仅在开始；尤其是，不会在CREATE RULE中INSERT INTO中失败(Tom)

在块退出时完全清理PL/pgSQL错误状态变量(Ashesh Vashi和Dave Page)

这不是PL/pgSQL本身存在的问题，但当检查一个函数的状态的时候，该疏忽可能导致PL/pgSQL调试器崩溃。

在Windows上重新尝试失败调用到CallNamedPipe()(Steve Marshall, Magnus)

看起来这个函数有时可能会暂时失效; 我们之前将任何故障看作是严重的错误， 这可能混淆LISTEN/NOTIFY以及其它操作。

添加MUST (Mauritius Island Summer Time)到已知的时区缩写缺省列表中(Xavier Bugaud)