to_char() 的數字格式掩碼

Question

你能解釋以下查詢之間的區別嗎

SELECT TO_CHAR(1980.55,'$9,999D999') FROM DUAL;

和

SELECT TO_CHAR(1980.55,'$9G999D999') FROM DUAL;

第一個查詢失敗並出現錯誤，我不明白的是組分隔符默認為 ',' 那么為什么一個失敗而另一個執行成功。

Answer 1

有趣的是，以前沒有遇到過，但無法想象為什么要混合它們。 我在文檔中甚至在 MSO 上都找不到任何內容，所以我會推測......

您通過將逗號/句點與組分隔符/小數字符（ G或D ）混合而得到的 ORA-01481 錯誤是“無效數字格式模型”，這表明它純粹是在驗證字符串'$9,999D999' 。 看起來在這個階段它不知道你的NLS_NUMERIC_CHARACTER設置，即使它被傳遞給to_char()函數。 這似乎並不太不合理，因為相同的驗證將應用於存儲代碼（過程、包、視圖或其他任何內容），並且您不會期望基於 NLS 設置（即硬解析）重新驗證緩存查詢。

它猜測它可以通過 char 的第三個參數指定G和D的含義來安全地完成，但這似乎對於邊緣情況可能需要做很多工作，如果您對它們進行硬編碼，那么甚至還有無論如何，在模型中混合它們的點數較少。

因此，如果在驗證格式模型字符串時不知道G和D將如何在運行時進行評估， 文檔中列出的限制就會成為問題。 您的逗號應該是組分隔符還是十進制字符？ 如果在運行時您的十進制字符是. 那么格式將無效，因為您只能擁有其中之一。 同樣，如果模型是'9.999G999'那么如果您的組分隔符是. ，但如果是,不會。 在解析時而不是運行時失敗似乎更安全、更可靠。

或者換句話說，“組分隔符默認為, ”的點是在格式模型經過驗證之后，所以它沒有任何區別。

但是，正如我所說，推測內部結構從來都不是一個好主意。 當文檔說“逗號[或組分隔符]不能出現在數字格式模型中的十進制字符或句點的右側”時，文檔似乎有點誤導，因為它們根本不能共存。 可能值得提出文檔錯誤嗎？

---

一個類似的問題被提出作為針對 8i 的錯誤 1204892，並作為非錯誤關閉，並帶有評論“這是它設計的工作方式”。