Re: Should we throw error when converting a nonexistent/ambiguous timestamp?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Should we throw error when converting a nonexistent/ambiguous timestamp?
Дата
Msg-id 27156.1268701973@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Should we throw error when converting a nonexistent/ambiguous timestamp?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should we throw error when converting a nonexistent/ambiguous timestamp?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 15, 2010 at 7:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm starting to think that maybe we should throw error in these cases
>> instead of silently doing something that's got a 50-50 chance of being
>> wrong. �I'm not sure if the "assume standard time" rule is standardized,
>> but I think it might be better if we dropped it. �Thoughts?

> That seems overly picky and fairly pointless to me.  Generally I'm a
> big fan of the idea that obvious breakage is better than silent
> breakage, but in this case it seems highly likely that you'll still
> have silent breakage until such time as a time change rolls around.

Yes, that's true, the failure will only be apparent when a DST
transition is sufficiently close by.  However, the problem with the
current behavior is that the failure isn't obvious even then ---
you might not notice the data inconsistency until much later when
it's not possible to sort things out.

The current code behavior seems to me to be on par with, for example,
trying to intuit MM-DD versus DD-MM field orders.  We used to try to
do that, too, and gave it up as a bad idea.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Takahiro Itagaki
Дата:
Сообщение: Re: Ragged latency log data in multi-threaded pgbench
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Should we throw error when converting a nonexistent/ambiguous timestamp?