From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, 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>, 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 15:32:49 |
Message-ID: | 10980.1458142369@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com> wrote:
>> 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.
I concur with Vitaly that it's not this patch's job to make it easier to
change the epoch date. If you want to submit a patch for that purpose,
you're welcome to.
I have a bigger problem though: I see that the patch enforces AD 294277
as the endpoint for both integer and floating-point datetimes. This
contradicts the statement in the docs (section 8.5) that
Note that using floating-point datetimes allows a larger range of
timestamp values to be represented than shown above: from 4713 BC up
to 5874897 AD.
Since that is just about the only non-historical reason why somebody might
wish to use float timestamps, I'm rather reluctant to remove the feature,
especially without any discussion --- and I don't see any discussion of
this point upthread.
My feeling is we ought to preserve the old behavior here, which would
involve making JULIAN_MAXYEAR_FOR_TIMESTAMPS format-dependent and
adjusting the float values for the two derived constants; not much of a
problem code-wise. I think though that it would break quite a number of
the proposed new regression tests for the float case. TBH, I thought
the number of added test cases was rather excessive anyway, so I wouldn't
have a problem with just leaving out whichever ones don't pass with both
build options.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-16 15:36:06 | Re: Show dropped users' backends in pg_stat_activity |
Previous Message | Robert Haas | 2016-03-16 15:32:48 | Re: Idle In Transaction Session Timeout, revived |