Re: BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
От | Jeremy Ford |
---|---|
Тема | Re: BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1 |
Дата | |
Msg-id | 9b8ea02b0906211826m28628c5qa804110d63081ed2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #4862: different results in to_date() between 8.3.7 &
8.4.RC1
|
Список | pgsql-bugs |
Oracle 9i: YEAR MONTH METHOD1 METHOD2 2009 03 1/03/2009 1/03/2009 Oracle 10g: YEAR MONTH METHOD1 METHOD2 2009 03 1/03/2009 1/03/2009 Regards, Jeremy. On Sat, Jun 20, 2009 at 2:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Brendan Jurd <direvus@gmail.com> writes: > > I hope that answers your question. to_date() is by nature a weird > > beast with many strange corners in its behaviour, and it's hard to > > strike a balance between backwards compatibility and Least > > Astonishment. My personal preference would be for a 100% strict > > interpretation of the format pattern, and a pox on anyone who has been > > relying on sloppy patterns! But that's not very practical. I would > > welcome any suggestions for further refinements. > > My feeling about it is that we usually try to match Oracle's behavior > for to_date/to_char, so the $64 question is whether Oracle allows a > leading space in these same cases. Anyone have it handy to test? > > regards, tom lane >
В списке pgsql-bugs по дате отправления: