Re: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
От | Tom Lane |
---|---|
Тема | Re: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check |
Дата | |
Msg-id | 20606.1458173586@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Список | pgsql-hackers |
Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes: > There is an issue, mentioned in the thread above: >> postgres=# select >> postgres-# to_char(date_trunc('week', '4713-01-01 BC'::date),'day') >> postgres-# ,to_char(date_trunc('week', '4714-12-29 BC'::date),'day') >> postgres-# ,to_char(date_trunc('week', '4714-12-28 BC'::date),'day'); >> to_char | to_char | to_char >> -----------+-----------+----------- >> monday | monday | thursday >> (1 row) >> since 4714-12-28 BC and to the past detection when a week is starting >> is broken (because it is boundary of isoyears -4713 and -4712). BTW, I think the actual problem is that j2day() figured that coercing its argument to unsigned int would be sufficient to produce a sane answer for negative inputs. It isn't. Nobody sees this with inputs after 4714BC, but when probing in 4714 the code considers the reference point 4714-01-04, which has a negative Julian date and so we end up passing a negative date to j2day(). regards, tom lane
В списке pgsql-hackers по дате отправления: