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: Michael Paquier <michael@paquier.xyz>
Cc: Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@gmail.com>, Vik Fearing <vik@postgresfriends.org>, cary huang <hcary328@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-10-17T15:31:06Z
Lists: pgsql-hackers 
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Oct 17, 2023 at 01:40:18AM -0400, Tom Lane wrote:
>> makes the failure go away.  Unfortunately, I've not yet found another
>> way to make it go away :-(.  My upthread idea of using a local variable
>> instead of result->time is no help, and some other random code
>> alterations didn't change the results either.

> That may be a long shot, but even a modulo?

Yeah, the same thing occurred to me in the shower this morning, and it
does seem to work!  We can replace both loops with a %= operator, at
least if we're willing to assume C99 division semantics, which seems
pretty safe in 2023.  Your idea of doing a range check to skip the
division in typical cases is a refinement I'd not thought of, but
it seems like a good idea for performance.

(I see that the negative-starting-point case isn't covered in the
current regression tests, so maybe we better add a test for that.)

			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.