Horton

Re: Cannot find a working 64-bit integer type on Illumos

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2024-07-04T03:10:34Z
Lists: pgsql-hackers 
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

Commits

  1. Move pg_int64 back to postgres_ext.h

  2. pgbench: Make set_random_seed() 64-bit everywhere.

  3. Use PRI?64 instead of "ll?" in format strings (continued).

  4. Fix order of -I switches for building pg_regress.o.

  5. libpq: Deprecate pg_int64.

  6. Use PRI*64 instead of "ll*" in format strings (minimal trial)

  7. Fix header inclusion order in c.h.

  8. Use <stdint.h> and <inttypes.h> for c.h integers.

  9. Remove traces of BeOS.

  10. More correct way to check for existence of types, which allows to specify