Re: Extract epoch from Interval weird behavior
От | Peter Eisentraut |
---|---|
Тема | Re: Extract epoch from Interval weird behavior |
Дата | |
Msg-id | 3e0b6f70-1098-f895-76f7-883fe0a3c267@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Extract epoch from Interval weird behavior (Joseph Koshakow <koshy44@gmail.com>) |
Ответы |
Re: Extract epoch from Interval weird behavior
|
Список | pgsql-hackers |
On 24.02.22 03:35, Joseph Koshakow wrote: >> However when executing EXTRACT we first truncate >> DAYS_PER_YEAR to an integer, and then multiply it >> by the total years in the Interval >> /* this always fits into int64 */ >>> secs_from_day_month = ((int64) DAYS_PER_YEAR * (interval->month / MONTHS_PER_YEAR) + >>> (int64) DAYS_PER_MONTH * (interval->month % MONTHS_PER_YEAR) + >>> interval->day) * SECS_PER_DAY; >> Is this truncation on purpose? It seems like >> EXTRACT is not accounting for leap years in >> it's calculation. This was not intentional. The cast is only to make the multiplication happen in int64; it didn't mean to drop any fractional parts. > Oops I sent that to the wrong email. If this isn't intented I've created a patch > that fixes it, with the following two open questions > * DAYS_PER_YEAR_NUM is recalculated every time. Is there anyway > to convert a float directly to a numeric to avoid this? We really wanted to avoid doing calculations in numeric as much as possible. So we should figure out a different way to write this. The attached patch works for me. It's a bit ugly since it hardcodes some factors. Maybe we can rephrase it a bit more elegantly.
Вложения
В списке pgsql-hackers по дате отправления: