Re: BUG #18247: Integer overflow leads to negative width - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18247: Integer overflow leads to negative width
Date
Msg-id 36777.1702999340@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18247: Integer overflow leads to negative width  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #18247: Integer overflow leads to negative width
List pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes:
> On Tue, Dec 19, 2023 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thanks for looking!  Do you have an opinion about the int64-vs-double
>> question?

> To be honest, I don't have a preference on which one is better.  I think
> double is good enough for now as we don't need to worry about overflow
> with it.

After sleeping on it, I'm coming around to the idea that int64 will
be better.  The argument that convinces me is that using int64
provides a datatype-based clue that we are working with a width
and not a row count, cost, or selectivity number.  I don't feel
a need to go as far as invent a typedef alias like Cardinality;
but plain "double" in the planner tends to be a rowcount estimate,
which is not what we want people to think of.

I'll make that change and push it.

BTW, I think it's sufficient to fix this in HEAD.  The troublesome
example seems quite artificial to me, and we've not heard field
reports suggesting that people have had real problems here.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Richard Guo
Date:
Subject: Re: BUG #18252: Assert in CheckOpSlotCompatibility() fails when recursive union filters tuples in non-recursive term
Next
From: Richard Guo
Date:
Subject: Re: BUG #18247: Integer overflow leads to negative width