Pavel Borisov <pashkin.elfe@gmail.com> writes:
> чт, 19 нояб. 2020 г. в 09:29, Greg Stark <stark@mit.edu>:
>> Wait, is configuring with a Perl that has 32-bit time_t driving the
>> rest of Postgres to use 32-bit timestamps? That seems like the tail
>> wagging the dog.
>> It seems like a sensible compromise would be to have Postgres's
>> configure default to 64-bit time_t and have a flag to choose 32-bit
>> time_t and then have a configure check that errors out if the time_t
>> in Perl doesn't match with a hint to either find a newer Perl
>> distribution or configure with the flag to choose 32-bit. Ie, don't
>> silently assume users want 32-bit time_t but leave them the option to
>> choose it explicitly.
> _USE_32BIT_TIME_T is available only on 32-bit platforms so the proposed
> flag will not be able to force 32-bit time_t, only allow it. On 64-bit
> platforms, we simply do not have a choice.
> I suppose that some 10+ years later the number of users willing to compile
> on 32-bit with dinosaur-aged Perl distribution will be nearly zero. So I
> suppose just mention this would be a funny fact in the documentation.
Yeah. I can't get excited about putting additional effort, and
user-visible complexity, into this issue. The only way it could matter
to people building Postgres today is if you suppose that the executables
they are building today will still be in use in 2038. That seems a bit
hard to credit. Ten years from now, that'd be a legitimate worry ...
but it's really hard to believe that these toolchains will still be
in use then.
(I would not be too surprised if we've dropped support for 32-bit
builds altogether by 2030. Certainly, any platform that still
has 32-bit time_t by then is going to be in a world of hurt.)
regards, tom lane
