On Wed, Aug 06, 2025 at 01:07:25PM +0200, Peter Eisentraut wrote:
> It turned out this had a bug, and also the newly added test cases didn't
> actually cover the new code, otherwise this would have shown up.
>
> Please review the attached patches with additional test cases and the fix.
>
> See also [0] for further context:
>
> [0]: https://www.postgresql.org/message-id/8246d7ff-f4b7-4363-913e-827dadfeb145%40eisentraut.org
Yes, confirmed the broken case on 32-bit builds with the incorrect
result returned by timestamptz_trunc_internal():
SELECT date_trunc( 'week', timestamp with time zone 'infinity' );
And confirmed that we don't have any coverage for two code paths as of
HEAD:
- "not supported" in timestamp_trunc() for the entire new section of
where TIMESTAMP_NOT_FINITE() is satisfied.
- "not supported" in timestamptz_trunc_internal() for the entire
section where TIMESTAMP_NOT_FINITE() is satisfied.
0001 adds three new tests for timestamp:
- TIMESTAMP_NOT_FINITE + a valid unit, new path.
- TIMESTAMP_NOT_FINITE + "not supported" unit, new error path
- !TIMESTAMP_NOT_FINITE + "not supported" unit, old error path
0001 four new tests for timestamptz:
1) Three tests for timestamptz_trunc():
- TIMESTAMP_NOT_FINITE + a valid unit, new path.
- TIMESTAMP_NOT_FINITE + "not supported" unit, new path.
- !TIMESTAMP_NOT_FINITE +
2) One test for timestamptz_trunc_zone():
- !TIMESTAMP_NOT_FINITE + "not supported" unit
With what I am reading in your patch, what you are suggesting to add,
and a double-check at the interval tests, that seems complete to me.
This is a v18 open item, for something that I am an owner of as the
committer of d85ce012f99f, so I'll go take care of it. Thanks!
--
Michael
