Nick Babadzhanian writes:
> Please find attached the v2 of the said patch with the tests added.
Pushed with light editing (for instance, I don't think interval.sql
is the place to test timestamp operators, even if the result is an
interval).
> I don't know how the decision on
> backpatching is
On Thu, Feb 16, 2023 at 1:12 AM Tom Lane wrote:
> Yeah, I don't think this would create a performance problem, at least not
> if you're using a compiler that implements pg_sub_s64_overflow reasonably.
> (And if you're not, and this bugs you, the answer is to get a better
Please find attached the
Andrey Borodin writes:
> On Wed, Feb 15, 2023 at 7:08 AM Nikolai wrote:
>> The patch attached simply throws an error when an overflow is
>> detected. However I'm not sure this is a reasonable approach for a
>> code path that could be very hot in some workloads.
> Given the extraordinary amount
On Wed, Feb 15, 2023 at 7:08 AM Nikolai wrote:
>
> The patch attached simply throws an error when an overflow is
> detected. However I'm not sure this is a reasonable approach for a
> code path that could be very hot in some workloads.
Given the extraordinary amount of overflow checks in the
Hello hackers,
I've been testing various edge-cases of timestamptz and related types
and noticed that despite being a 16-byte wide type, interval overflows
for some timestamptz (8-byte) subtractions (timestamp_mi).
A simple example of this would be:
select timestamptz'294276-12-31 23:59:59 UTC'
