Joseph Koshakow writes:
> On Sat, Feb 19, 2022 at 12:00 PM Tom Lane wrote:
>> 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 interva
On Sat, Feb 19, 2022 at 12:00 PM Tom Lane wrote:
> 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
> decoding.
Yeah that's a g
Joseph Koshakow writes:
> On Fri, Feb 18, 2022 at 11:44 PM Tom Lane 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
>> hardware.
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > When formatting the output of an Interval, we call abs() on the hours
> > field of the Interval. Calling abs(INT_MIN) returns back INT_MIN
> > causing the output to contain two '-' characters. The attached patch
> >
Joseph Koshakow writes:
> When formatting the output of an Interval, we call abs() on the hours
> field of the Interval. Calling abs(INT_MIN) returns back INT_MIN
> causing the output to contain two '-' characters. The attached patch
> fixes that issue by special casing INT_MIN hours.
Good catch,
When formatting the output of an Interval, we call abs() on the hours
field of the Interval. Calling abs(INT_MIN) returns back INT_MIN
causing the output to contain two '-' characters. The attached patch
fixes that issue by special casing INT_MIN hours.
Here is an example of the issue:
postgre
