Re: A creepy story about dates. How to prevent it?
От | nolan@celery.tssi.com |
---|---|
Тема | Re: A creepy story about dates. How to prevent it? |
Дата | |
Msg-id | 20030619165030.31618.qmail@celery.tssi.com обсуждение исходный текст |
Ответ на | Re: A creepy story about dates. How to prevent it? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: A creepy story about dates. How to prevent it?
|
Список | pgsql-general |
> nolan@celery.tssi.com writes: > >> Anyone care to run some tests to see how lax Oracle's to_date is? > > > Oracle's to_date function is not lax at all. > > Then we need to fix ours. Karel? To make it as strict as Oracle's? I'm not entirely convinced that is a Good Thing. However, if that is to be done, would it also be possible to define a 'check_date' function which does the same as 'to_date' but returns NULL (or some kind of error code) rather than a SQL error on an invalid date? I've never tried it (and am somewhat embarassed to say that I had not even considered the idea until today), but it should possible in Oracle's PL/SQL to use exception handling to trap to_date errors. (I always wound up using oraperl's error handling capabilities to detect bad dates when porting data to Oracle.) Would that be possible in pgplsql, does it support the same levels of exception handling as PL/SQL? -- Mike Nolan
В списке pgsql-general по дате отправления: