Mark Dilger <hornschnor...@gmail.com> writes: >> On Mar 14, 2016, at 5:12 PM, Vitaly Burovoy <vitaly.buro...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers