# E.63\. 發布8.3.14 > **發布日期:** 2011-01-31 該發布包含來自8.3.13中各種修復。關于8.3主要發布中新特性信息， 參閱[Section E.77](#calibre_link-34)。 ## E.63.1\. 遷移到版本8.3.14 運行8.3.X不需要備份/恢復。然而，如果從8.3.8更早版本更新， 參閱8.3.8發布說明。 ## E.63.2\. 變化 * 當`EXPLAIN`嘗試顯示簡單形式`CASE`表達式的時候， 避免錯誤(Tom Lane) 如果`CASE`的測試表達式是一個常量，那么規劃器可以簡化 `CASE`到迷惑表達式顯示代碼的一種形式中， 導致"意外CASE WHEN子句"錯誤。 * 修復下標現有范圍之前數組片段的分配(Tom Lane) 如果在新添加的下標和最初預先存在的下標之間有間隙， 那么代碼誤算需要從舊數組空位圖中拷貝多少項， 有可能導致數據損壞或崩潰。 * 避免規劃遙遠日期值中意外轉換溢出(Tom Lane) `date`類型支持比`timestamp`類型表示的更廣泛的日期， 但規劃器假定它可能總是轉換日期到timestamp。 * 當`standard_conforming_strings`是on的時候， 修復大對象(BLOBs)pg_restore的文本輸出(Tom Lane) 雖然直接恢復到數據庫正常執行，如果pg_restore被要求 SQL文本輸出并且源數據庫中已經啟用`standard_conforming_strings`， 那么字符串逃避是不正確的。 * 修復包含`... & !(subexpression) | ...`的`tsquery`值 的錯誤解析(Tom Lane) 不能正確執行包含操作符合并的查詢。`contrib/intarray`的 `query_int`類型和`contrib/ltree`的 `ltxtquery`類型中存在同樣的錯誤。 * 為`query_int`類型修復`contrib/intarray`的輸入函數中的緩沖區溢出(Apple) 該錯誤是一個安全風險，因為函數的返回地址可能被重寫。感謝Apple Inc的安全團隊報告這個問題 并且提供修復(CVE-2010-4015) * 修復`contrib/seg`的GiST picksplit算法錯誤(Alexander Korotkov) 這可能導致效率低下，盡管不是真的錯誤答案，在`seg`列的GiST索引中。 如果你有一個索引，在安裝這個更新之后考慮`REINDEX`它。 （這與之前更新中`contrib/cube`中修復的錯誤是一樣的）