чт, 19 нояб. 2020 г. в 09:29, Greg Stark <stark@mit.edu>:
On Wed, 18 Nov 2020 at 12:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: > > On 11/18/20 9:44 AM, Tom Lane wrote: > >> Hmm. Digging around, I see that Mkvcbuild.pm intentionally absorbs > >> _USE_32BIT_TIME_T when building with a Perl that defines that. > >> I don't know what the state of play is in terms of Windows Perl > >> distributions getting off of that, but maybe we should press people > >> to not be using such Perl builds. > > > I think there's a good argument to ban it if we're doing a 64 bit build > > (and why would we do anything else?) > > I'm not really eager to ban it. If somebody is building with an old > Perl distribution, and doesn't particularly care that the installation > will break in 2038, why should we force them to care?
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.
