Re: Possible api miuse bms_next_member - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Possible api miuse bms_next_member
Date
Msg-id 181792.1744208318@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible api miuse bms_next_member  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Possible api miuse bms_next_member
List pgsql-hackers
Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> On Wed, 9 Apr 2025 at 15:01, Ranier Vilela <ranier.vf@gmail.com> wrote:
>> Coverity has two new reports about use of the function *bms_next_member*.
>> I think that he is right.

> I don't know much about the planner, but I would expect a RelOptInfo's
> relids field to always contain at least one relid when it's not
> currently being constructed; thus guaranteeing a non-negative result
> when looking for the first bit (as indicated by "next bit after -1").

Indeed.  These patches are all useless IMO.  I'm not sure that this
is really a great way to select a representative member of the
child-relids set, but it won't fail, and if it did we'd have way
worse problems.  (For starters: if a child rel's relids set is
empty, then presumably so was the parent's, meaning we cannot
tell them apart.)

If we did want to do something about this warning, rather than
hacking up the call sites I'd be inclined to invent something like
"bms_first_member()" which does the same thing but additionally
asserts on empty input.  Not really convinced it's worth the
trouble though.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cleaning up ERRCODE usage in our XML code
Next
From: Tom Lane
Date:
Subject: Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c