Re: Fix overflow in DecodeInterval - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Fix overflow in DecodeInterval
Date
Msg-id 20220213203037.ie7bgjrodupzxhda@alap3.anarazel.de
Whole thread Raw
In response to Re: Fix overflow in DecodeInterval  (Joseph Koshakow <koshy44@gmail.com>)
Responses Re: Fix overflow in DecodeInterval  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-02-13 09:35:47 -0500, Joseph Koshakow wrote:
> I chose int return types to keep all these methods
> consistent with DecodeInterval, which returns a
> non-zero int to indicate an error.

That's different, because it actually returns different types of errors. IMO
that difference is actually reason to use a bool for the new cases, because
then it's a tad clearer that they don't return DTERR_*.

> Though I wasn't sure
> if an int or bool would be best, so I'm happy to change
> to bool if people think that's better.

+1 or bool.


> Also I'm realizing now that I've incorrectly been using the
> number of the patch to indicate the version, instead of just
> sticking a v3 to the front. So sorry about that, all the patches
> I sent in this thread are the same patch, just different versions.

No worries ;)


Do we want to consider backpatching these fixes? If so, I'd argue for skipping
10, because it doesn't have int.h stuff yet. There's also the issue with
potentially breaking indexes / constraints? Not that goes entirely away across
major versions...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: [PATCH] Dereference null return value (NULL_RETURNS) (src/backend/commands/statscmds.c)
Next
From: Chapman Flack
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT