On Wed, Feb 1, 2023 at 8:13 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Tue, 31 Jan 2023 15:12:14 +0530, Amit Kapila <amit.kapil...@gmail.com> > wrote in > > On Tue, Jan 31, 2023 at 1:40 PM Kyotaro Horiguchi > > <horikyota....@gmail.com> wrote: > > > > > > Hi, Kuroda-san, Thanks for the detailed study. > > > > > > At Tue, 31 Jan 2023 07:06:40 +0000, "Hayato Kuroda (Fujitsu)" > > > <kuroda.hay...@fujitsu.com> wrote in > > > > Therefore, I think we can say that modern platforms that are supported > > > > by PostgreSQL define int as 32-bit. > > > > It satisfies the condition sizeof(int) <= sizeof(int32), so we can keep > > > > to use INT_MAX. > > > > > > Yeah, I know that that's practically correct. Just I wanted to make > > > clear is whether we (always) assume int == int32. I don't want to do > > > that just because that works. Even though we cannot be perfect, in > > > this particular case the destination space is explicitly made as > > > int32. > > > > > > > So, shall we check if the result of parse_int is in the range 0 and > > PG_INT32_MAX to ameliorate this concern? > > Yeah, it is exactly what I wanted to suggest. > > > If this works then we need to > > probably change the return value of defGetMinApplyDelay() to int32. > > I didn't thought doing that, int can store all values in the valid > range (I'm assuming we implicitly assume int >= int32 in bit width) > and it is the natural integer in C. Either will do for me but I > slightly prefer to use int there. >
I think it would be clear to use int32 because the parameter where we store the return value is also int32. -- With Regards, Amit Kapila.
