Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
От | Vitaly Burovoy |
---|---|
Тема | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check |
Дата | |
Msg-id | CAKOSWNkwNBR42sEcbgpVfKEvWJ_HksxPY2UM_qCr9wPamv13=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
|
Список | pgsql-hackers |
On 3/16/16, Tom Lane <tgl@sss.pgh.pa.us> wrote: > So I fixed that up and committed it, with a very short set of new > regression test cases. I seriously doubt that the other ones add > enough value to be worth trying to make them work in both float- and > int-timestamp cases; though if you want to submit a new patch to > add more test cases we could consider it. My feeling about it is that > that kind of testing does nothing for errors of omission (ie functions > that fail to range-check their results), which is the most likely sort > of bug here, and so I doubt it's worth adding them to regression tests > that many people will run many times a day for a long time to come. > > regards, tom lane Thank you very much! If you decide such kind of tests is not necessary, it is enough for me. Is there any reason to leave JULIAN_MINDAY and JULIAN_MAXDAY which are not used now? Also why JULIAN_MAXMONTH is set to "6" whereas {DATE|TIMESTAMP}_END_JULIAN use "1" as month? -- Best regards, Vitaly Burovoy
В списке pgsql-hackers по дате отправления: