# 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)