|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Joseph Koshakow <koshy44(at)gmail(dot)com>|
|Subject:||Re: Fix formatting of Interval output|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Joseph Koshakow <koshy44(at)gmail(dot)com> writes:
> On Fri, Feb 18, 2022 at 11:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wonder if the most reasonable fix would be to start using int64
>> instead of int arithmetic for the values that are potentially large.
>> I doubt that we'd be taking much of a performance hit on modern
> That's an interesting idea. I've always assumed that the range of the
> time fields of Intervals was 2147483647 hours 59 minutes
> 59.999999 seconds to -2147483648 hours -59 minutes
> -59.999999 seconds. However the only reason that we can't support
> the full range of int64 microseconds is because the struct pg_tm fields
> are only ints. If we increase those fields to int64 then we'd be able to
> support the full int64 range for microseconds as well as implicitly fix
> some of the overflow issues in DecodeInterval and EncodeInterval.
I think that messing with struct pg_tm might have too many side-effects.
However, pg_tm isn't all that well adapted to intervals in the first
place, so it'd make sense to make a new struct specifically for interval
regards, tom lane
|Next Message||Andres Freund||2022-02-19 17:03:14||Re: Reducing power consumption on idle servers|
|Previous Message||Joseph Koshakow||2022-02-19 16:40:38||Re: Fix formatting of Interval output|