On Sun, 2026-07-26 at 18:39 -0700, Jacob Brazeal wrote: > I found an interesting exception to the principle here [0] that timestamp vs. > timestamptz > comparisons of the datetime_ops btree family are always consistently ordered: > a DST > spring-forward gap. > > [...] > > This seems maybe annoying to fix, but the alternative could be adding some > documentation about it?
It is quite unacceptable to allow a bad query result, so documenting this is not good enough in my opinion. Since the problem is the implicit cast from timestamp to timestamptz, an index scan would be fine for certain values of the "timezone" parameter, but we cannot know the setting at query planning time. I'd say that the fix is not to attempt an index scan in such a situation, that is, to remove those operators from the operator family. I am not sure what to do in the back branches, though. Yours, Laurenz Albe
