From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Cannot find a working 64-bit integer type on Illumos |
Date: | 2024-07-04 03:10:34 |
Message-ID: | 3329541.1720062634@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> New version attached. This time I was brave enough to try to tackle
> src/timezone too, which had comments planning to drop a lot of small
> differences against the upstream tzcode once all supported branches
> required C99.
Unless you've specifically checked that this reduces diffs against
upstream tzcode, I'd really prefer not to touch that code right now.
I know I'm overdue for a round of syncing src/timezone/ with upstream,
but I can't see how drive-by changes will make that easier.
> IMHO it's a rather scary choice on tzcode's part to use int_fastN_t,
Yeah, I was never pleased with that choice of theirs. OTOH, I've
seen darn few portability complaints on their mailing list, so
it seems like they've got it right in isolation. The problem
from our standpoint is that I don't think we want int_fastN_t
to leak into APIs visible to the rest of Postgres, because then
we risk issues related to their configuration methods being
totally unlike ours.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-07-04 03:11:02 | Re: Pluggable cumulative statistics |
Previous Message | torikoshia | 2024-07-04 03:05:25 | Re: Add new COPY option REJECT_LIMIT |