On Thu, Jul 4, 2024 at 3:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Sure, I'll wait until you say it's a good time. It does remove a
dozen or so hunks of difference, which should hopefully make that job
easier eventually but I don't want to get in your way. I can see
there are a few more trivialities we could synchronise on, like const
keywords, to kill useless diffs (either dropping local improvements or
sending patches upstream).
> > 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.
Yeah. My first swing at this touched only .c files, no .h files, with
that in mind.
