Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Date
Msg-id 58BF713F-D61F-4C17-A591-B85FE8719660@gmail.com
Whole thread Raw
In response to Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
List pgsql-hackers
> 
>>>> The #defines would be less brittle in
>>>> the event, for example, that the postgres epoch were ever changed.
>>> 
>>> I don't think it is real, and even in such case all constants are
>>> collected together in the file and will be found and changed at once.
>> 
>> I agree that they would be found at once.  I disagree that the example
>> is not real, as I have changed the postgres epoch myself in some builds,
>> to be able to use int32 timestamps on small devices.
> 
> Wow! I'm sorry, I didn't know about it.
> But in such case (tighten to int32) there are more than two places
> which should be changed. Two more (four with disabled
> HAVE_INT64_TIMESTAMP) constants are not big deal with it.

Please, do not worry about that.  I do not mean that your code needs
to be compatible with my fork.

Regards,
Mark Dilger






pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Next
From: Jim Nasby
Date:
Subject: Re: fd.c doesn't remove files on a crash-restart