чт, 19 нояб. 2020 г. в 09:29, Greg Stark <st...@mit.edu>: > 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. >
_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. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
