多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
# E.70\. 发布8.3.7 > **发布日期:** 2009-03-16 该发布包含来自8.3.6中各种修复。关于8.3主要发布中新特性信息, 参阅[Section E.77](#calibre_link-34)。 ## E.70.1\. 迁移到版本8.3.7 运行8.3.X不需要备份/恢复。然而,如果从8.3.5更早版本更新,参阅8.3.5发布说明。 ## E.70.2\. 变化 * 当编码转换失败的时候,避免错误递归崩溃(Tom) 该变化为相关错误情况在最后两个次要版本中扩展修复。 之前修复程序为最初问题报告进行了细化, 但我们现在已经认识到通过编码转换函数抛出的_任何_错误 可能潜在地导致无限递归,而试图报告错误。 如果我们发现已经卷入了一个递归错误报告的情况时, 解决的办法是禁用转换以及编码转换并报告任何纯ASCII格式错误消息。 * 不允许为指定转换函数带有错误编码的`CREATE CONVERSION`(Heikki) 这可以防止编码转换失败的情况。之前变化是预防同一区域其它类型错误的手段。 * 修复`xpath()`不会修改路径表达式除非必要,并且当必要时做出理智尝试(Andrew) SQL标准表明`xpath`致力于数据是一个文档片段, 但libxml不支持这一点, 其实这是不明确的,按照XPath标准是明智的。 `xpath`试图通过修改数据和路径表达式解决这个错误匹配, 但是修改是古怪的,并可能导致有效的搜索失败。现在, `xpath`检查数据是否实际上是一个良好的文档, 并且如果是这样调用不改变数据或路径表达式的libxml。 否则,一个不太可能失败的不同修改方法被使用。 > **Note:** 新的修改方法仍然不是100%令人满意,并且它 似乎没有真正的解决方案是可能的。 这个补丁因此被看作是一个短期有效的防止不必要的破坏现有应用程序。 PostgreSQL 8.4直接拒绝在不是一个良好文档的数据上使用`xpath`。 * 当`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)