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，restrictions listed in the documentation就成了问题。您的逗号应该是组分隔符还是小数字符？如果在运行时您的十进制字符为.，那么格式将无效，因为您只能有其中一个。同样，如果模型为'9.999G999'，那么如果您的论坛分隔符为.，则有效，但如果它是,则无效。在解析时而不是运行时失败似乎更安全，更可靠。

或者换句话说，在格式模型验证之后，“组分隔符默认为,”的位置是，因此它没有任何区别。

但是，正如我所说，推测内部，这从来都不是一个好主意。当文档说'逗号[或组分隔符]不能出现在数字格式模型中的十进制字符或句点的右侧时，文档似乎有点误导，因为它们根本不能共存。可能值得提出文档错误吗？

---

类似的问题被提出作为针对8i的错误1204892，并且作为非错误的评论关闭'这是它的设计工作方式'。