Re: A creepy story about dates. How to prevent it?

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: A creepy story about dates. How to prevent it?
Дата
Msg-id Pine.LNX.4.33.0306190804300.7044-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: A creepy story about dates. How to prevent it?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Nigel J. Andrews"
Дата:
Сообщение: Re: why are my SELECTs in transaction?
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Incremental backups, and backup history