Re: A creepy story about dates. How to prevent it? - Mailing list pgsql-general

From nolan@celery.tssi.com
Subject Re: A creepy story about dates. How to prevent it?
Date
Msg-id 20030619165030.31618.qmail@celery.tssi.com
Whole thread Raw
In response to Re: A creepy story about dates. How to prevent it?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A creepy story about dates. How to prevent it?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Ron Johnson
Date:
Subject: Re: A creepy story about dates. How to prevent it?
Next
From: Andrew Ayers
Date:
Subject: Re: Performance differences using varchar, char and text