From: | "Brandon Aiken" <BAiken(at)winemantech(dot)com> |
---|---|
To: | "Scott Ribe" <scott_ribe(at)killerbytes(dot)com>, "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Finding bogus dates |
Date: | 2007-01-18 21:17:53 |
Message-ID: | F8E84F0F56445B4CB39E019EF67DACBA44F06A@exchsrvr.winemantech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Actually, now that I think about it a second you can find them really
easy just by doing:
SELECT * FROM "foo"
WHERE to_char(to_date("oldDate",'MM/DD/YYYY'),'MM/DD/YYYY') <>
"oldDate";
--
Brandon Aiken
CS/IT Systems Engineer
-----Original Message-----
From: Scott Ribe [mailto:scott_ribe(at)killerbytes(dot)com]
Sent: Thursday, January 18, 2007 3:48 PM
To: Brandon Aiken; pgsql-general postgresql.org
Subject: Re: [GENERAL] Finding bogus dates
I didn't know to_date would do that. It's better anyway. I just
continued
with the "fix and try again" approach and they're only 2 bad dates out
94,000+, so I don't have a huge problem here. I can try to do some
research
and find the correct date, but failing that, the to_date approximation
is
probably no worse than using null.
--
Scott Ribe
scott_ribe(at)killerbytes(dot)com
http://www.killerbytes.com/
(303) 722-0567 voice
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2007-01-18 21:21:56 | Re: Finding bogus dates |
Previous Message | volunteer | 2007-01-18 21:17:10 | apt-get install postgresql.deb?? |