Re: [GENERAL] to_timestamp() and quarters
От | Bruce Momjian |
---|---|
Тема | Re: [GENERAL] to_timestamp() and quarters |
Дата | |
Msg-id | 201003031425.o23EPTw25883@momjian.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] to_timestamp() and quarters ("Albe Laurenz" <laurenz.albe@wien.gv.at>) |
Список | pgsql-hackers |
Albe Laurenz wrote: > > But stop, now i see: > > > > test=*# select to_date('2010-02-29', 'YYYY-MM-DD'); > > to_date > > ------------ > > 2010-03-01 > > (1 row) > > > > So it is maybe a congruously behavior ;-) > > Ugh. I thought that to_date was an Oracle compatibility function. > > SQL> select to_date('2010-02-29', 'YYYY-MM-DD') from dual; > select to_date('2010-02-29', 'YYYY-MM-DD') from dual > * > ERROR at line 1: > ORA-01839: date not valid for month specified > > And for that matter: > > SQL> select to_date('2010-7', 'YYYY-Q') from dual; > select to_date('2010-7', 'YYYY-Q') from dual > * > ERROR at line 1: > ORA-01820: format code cannot appear in date input format > > Oracle allows Q only when converting date to string. > So this can be seen as an extension. > > But allowing 2010-02-29 is incompatible and smacks of MySQL... Yea, we had a similar issue with to_timestamp(): test=> SELECT to_timestamp('20096040','YYYYMMDD'); to_timestamp------------------------ 2014-01-17 00:00:00-05(1 row) If we are going to tighten these up, we should do them all. Right now we allow it and for consistency should allow the Q=7 value too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
В списке pgsql-hackers по дате отправления: