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