# E.163\. 版本 7.4.20 > **發布日期:** 從未發布 這個版本包含各種自7.4.19以來的修復。關于7.4主版本的新特性的信息， 請查閱[Section E.183](#calibre_link-305)。 ## E.163.1\. 遷移到版本 7.4.20 運行7.4.X的用戶不需要轉儲/恢復。不過，如果你是從一個早于7.4.11的版本升級而來， 請查看7.4.11的版本聲明。 ## E.163.2\. 修改列表 * 修復ISO-8859-5和其他編碼之間的轉換，以處理Cyrillic "Yo"字符 （帶有兩個點的`e`和`E`） (Sergey Burladyan) * 修復一些數據類型輸入函數，他們允許未使用的字節在他們的結果中包含未初始化的、 不可預期的值 (Tom) 這會導致兩個表面上一樣的字面值不被認為相等的失敗，導致分析器抱怨不匹配的 `ORDER BY`和`DISTINCT`表達式。 * 修復正則表達式子字符串匹配中的極端情況 (`substring(``_string_` from `_pattern_`)) (Tom) 這個問題發生在有一個完全匹配的模式的時候，但是用戶已經指定了一個加括號的子表達式， 并且該子表達式沒有得到匹配。一個例子是`substring('foo' from 'foo(bar)?')`。 這個應該返回NULL，因為`(bar)`不匹配， 但是它錯誤的返回了整個模式匹配（也就是，`foo`）。 * 修復ecpg的`PGTYPEStimestamp_sub()` 函數中不正確的結果 (Michael) * 修復`DatumGetBool`宏使用gcc 4.3時不會失敗 (Tom) 這個問題影響"老式風格" (V0)的C函數返回布爾值。 該修復已經在8.3中，但是當時沒有意識到需要回來修補它。 * 修復長期存在的`LISTEN`/`NOTIFY`競態條件 (Tom) 在少數情況下，剛剛執行了一個`LISTEN`的會話可能不會得到一個通知， 即使應該這樣，因為并發事務執行`NOTIFY`會觀察到提交以后。 該修復的一個副作用是一個執行了還未提交的`LISTEN` 命令的事務將看不到任何在`pg_listener`中的行， 而它應該是能看到的；以前它也是能看到的。 這個行為從未有過這種或那種的記錄，但是一些依賴于老的行為的應用是有可能出現的。 * 修復`ORDER BY`和`GROUP BY`中常數表達式的顯示 (Tom) 一個明確轉換的常量會不正確的顯示。這會導致，例如轉儲和重載期間視圖定義損壞。 * 修復libpq以正確的處理COPY OUT期間的NOTICE消息 (Tom) 這個故障只在一個用戶定義的數據類型的輸出程序發出一個NOTICE時可以觀察到發生， 但是不保證它不會由于其他原因發生。