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

From scott.marlowe
Subject Re: A creepy story about dates. How to prevent it?
Date
Msg-id Pine.LNX.4.33.0306190804300.7044-100000@css120.ihs.com
Whole thread Raw
In response to Re: A creepy story about dates. How to prevent it?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Wed, 18 Jun 2003, Tom Lane wrote:

> "scott.marlowe" <scott.marlowe@ihs.com> writes:
> > On Wed, 18 Jun 2003, Tom Lane wrote:
> >> I do now seem to recall an agreement that a GUC switch to disable
> >> date-interpretation guessing would be okay, though.
>
> > I'm pretty sure it was the other way around, make strict locale / date
> > checking the standard and a GUC to turn it off for folks who really want
> > to use a broken database.  :-)
>
> This is definitely a case where what is "broken" is in the eye of the
> beholder.  If the current behavior is broken, why have we had so few
> complaints about it?  It's been like that for quite a few years now.
>
> I think that on grounds of backwards compatibility alone, we should
> leave the out-of-the-box default behavior as it is.

I thought of another "silent failure" scenario.

Imports.  If you have say 10,000 rows to import, and all the dates are in
euro style format going into a us style database, then all the ones where
the "month" is <13 will be put in wrong, and all the ones with a "month"
>12 will be silently converted to be right.  Now half the dates are right,
and half are wrong, and there's no error.

That's the worst of possibilities.  Better to fail grandly than silently
corrupt data.


pgsql-general by date:

Previous
From: "Nigel J. Andrews"
Date:
Subject: Re: why are my SELECTs in transaction?
Next
From: Greg Stark
Date:
Subject: Re: Incremental backups, and backup history