Horton

Re: Add support for AT LOCAL

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: Michael Paquier <michael@paquier.xyz>, Noah Misch <noah@leadboat.com>, Vik Fearing <vik@postgresfriends.org>, cary huang <hcary328@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-10-17T23:32:05Z
Lists: pgsql-hackers 
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Oct 18, 2023 at 11:54 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Should we be testing against xlclang instead?

> I hesitated to suggest it because it's not my animal/time we're
> talking about but it seems to make more sense.  It appears to be IBM's
> answer to the nothing-builds-with-this-thing phenomenon, since it
> accepts a lot of GCCisms via Clang's adoption of them.  From a quick
> glance at [1], it lacks the atomics builtins but we have our own
> assembler magic for POWER.  So maybe it'd all just work™.

Discounting the Windows animals, it looks like the xlc animals are
our only remaining ones that use anything except gcc or clang.
That feels uncomfortably like a compiler monoculture to me, so
I can understand the reasoning for keeping hornet/mandrill going.
Still, maybe we should just accept the fact that gcc/clang have
outcompeted everything else in the C compiler universe.  It's
getting hard to imagine that anyone would bring out some new product
that didn't try to be bug-compatible with gcc, for precisely the
reason you mention.

			regards, tom lane

Commits

  1. Dodge a compiler bug affecting timetz_zone/timetz_izone.

  2. Back-patch test cases for timetz_zone/timetz_izone.

  3. Add regression test coverage for timetz_izone().

  4. Add support for AT LOCAL

  5. doc: Mention timezone(zone, time) in section for AT TIME ZONE

  6. Use HASH_BLOBS for xidhash.