| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, 方徳輝 <javaeecoding(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is postgres ready for 2038? |
| Date: | 2020-11-18 15:27:20 |
| Message-ID: | CALT9ZEFSr-Wf0Ru9vCy7eOf3K3jcdh3tmzeh1-p+o8ZVdQjbUw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Yes, I agree.
ср, 18 нояб. 2020 г. в 18:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> writes:
> >> Maybe we need to dig a little more to see what's going on here.
>
> > How about just a mention in the future documentation to never ever define
> > _USE_32BIT_TIME_T when compiling PG under Windows? Should be enough, I
> > suppose.
>
> 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.
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-11-18 15:49:33 | Re: Tab complete for CREATE OR REPLACE TRIGGER statement |
| Previous Message | Tels | 2020-11-18 15:25:44 | Re: Tab complete for CREATE OR REPLACE TRIGGER statement |