On Thu, Jul 4, 2024 at 3:10 PM Tom Lane <t...@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.
