From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Heikki Linnakangas <hlinnaka@iki.fi>,
        Peter Eisentraut <peter@eisentraut.org>,
        Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Cannot find a working 64-bit integer type on Illumos
In-reply-to: <CA+hUKG+rYp-=fTP5kjRmnfPq7YgK-e=J+gJxBvKarkPVzLwQmQ@mail.gmail.com>
References: <ME3P282MB3166F9D1F71F787929C0C7E7B6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM> <20240322165305.6zrtxcmzdrywvmsu@awork3.anarazel.de> <ME3P282MB3166D876E9CB83009727A5ECB6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM> <944094.1711128356@sss.pgh.pa.us> <CA+hUKG+CR05ACFujUbeAd-yM+nNJBSpnyB=q3vbriCJuoSu9Ag@mail.gmail.com> <1229869.1711160593@sss.pgh.pa.us> <CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com> <7cf1dcb7-306f-4418-bf25-bdc75130db10@eisentraut.org> <CA+hUKGKXEdVSfR6UHXfR3tSQ+TfBNk-ssYmO2F0wCdw7qcx86Q@mail.gmail.com> <d8d68452-7195-41cf-a31b-e660f5ac6e75@iki.fi> <CA+hUKG+rYp-=fTP5kjRmnfPq7YgK-e=J+gJxBvKarkPVzLwQmQ@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Thu, 04 Jul 2024 14:55:59 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3329540.1720062634.1@sss.pgh.pa.us>
Date: Wed, 03 Jul 2024 23:10:34 -0400
Message-ID: <3329541.1720062634@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3329541.1720062634%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.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