Re: Extract epoch from Interval weird behavior - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Extract epoch from Interval weird behavior
Date
Msg-id 3e0b6f70-1098-f895-76f7-883fe0a3c267@enterprisedb.com
Whole thread Raw
In response to Re: Extract epoch from Interval weird behavior  (Joseph Koshakow <koshy44@gmail.com>)
Responses Re: Extract epoch from Interval weird behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.
Attachment

pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Lowering the ever-growing heap->pd_lower
Next
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning