On Wed, 18 Nov 2020 at 12:22, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andrew Dunstan <and...@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. -- greg