Oracle to_date的一点剖析

晚上在回答chinaunix上的一个题目。
这个题目在我们的开发过程中很经常遇见。
在此简单记录一下：

也就是to_date为什么有时候会报错呢？

http://bbs.chinaunix.net/viewthread.php?tid=905631&extra=page%3D1

确保客户端 NLS_LANG = AMERICAN_AMERICA.UTF8

SQL> SELECT *
2 FROM V$NLS_PARAMETERS
3 where parameter = 'NLS_DATE_FORMAT';

PARAMETER
----------------------------------------------------------------------
VALUE
----------------------------------------------------------------------
NLS_DATE_FORMAT
DD-MON-RR


SQL> select to_date(sysdate,'dd-mon-rr') from dual;

TO_DATE(SYSDATE
---------------
06-MAR-07

如下写法是错误的：

SQL> select to_date(sysdate,'yyyy-mm-dd') from dual;

 可能于oracle本是的date数据类型的格式有关系

应该写成

SQL> select to_date(to_char(sysdate,'yyyy-mm-dd'),'yyyy-mm-dd') from dual;

我觉得对TO_DATE这个函数的使用上有点不妥。理由如下：
在说明理由之前要明白以下几点。
1.TO_DATE有几个参数，它们的类型是什么？
TO_DATE有三个参数，它们的类型都是字符串。
第一个参数用来表示日期，第二个参数是用来表明第一个参数中日期的格式。就是表示字符中各部分对应日期中的哪一部分。
第三个是表明语言信息的，很少用。
2.TO_DATE的返回值是什么？
返回值是日期。

理由有
I.TO_DATE的使用上
它的第一个参数是字符串但传入的却是日期类型的SYSDATE,系统定会以系统的约定方式将其做类型转换，这样对第二个参数的使用上将充满了变数。
我觉得楼主的方法不能从根本解决问题，除非在用到这样的TO_DATE之前，查一下系统中对日期格式的定义，显然这样做也不太好。
另外对楼主所说的"确保客户端 NLS_LANG = AMERICAN_AMERICA.UTF8"。我觉得这一点不是问题的关键所在。
II.从程序的可移植/灵活性上考虑
其实在第I点中也隐约提到了这一点。这种可移植性是指如果写的这段代码要转移到另一个数据库中，很有可能再次出现问题，灵活性是指当数据库的默认日期格式改变了，写的这段代码也要做相应的改变。
所以最好的解决方法应该是
SELECT TO_DATE(TO_CHAR(SYSDATE,'DD-MON-RR'),'DD-MON-RR') FROM DUAL;
这样，一切都在自己的掌握之中了。