| From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
|---|---|
| To: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> |
| Cc: | David Steele <david(at)pgmasters(dot)net>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check |
| Date: | 2016-03-16 22:01:51 |
| Message-ID: | 58BF713F-D61F-4C17-A591-B85FE8719660@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2016-03-16 22:16:14 | Re: fd.c doesn't remove files on a crash-restart |
| Previous Message | Vitaly Burovoy | 2016-03-16 21:47:52 | Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check |