On Sep 15 2025, at 3:03 pm, Greg Burd <g...@burd.me> wrote:
> On Sep 15 2025, at 2:54 pm, Robert Haas <robertmh...@gmail.com> wrote:
>
>> On Mon, Sep 15, 2025 at 2:00 PM Greg Burd <g...@burd.me> wrote:
>>> For reference radixtree has:
>>>
>>> coverage: HEAD
>>> lines......: 98.3
>>> functions..: 97.2
>>> branches...: 89.4
>>
>> + /* Test negative member in bms_make_singleton */
>> + error_caught = false;
>> + PG_TRY();
>> + {
>> + bms_make_singleton(-1);
>> + }
>> + PG_CATCH();
>> + {
>> + error_caught = true;
>> + FlushErrorState();
>> + }
>> + PG_END_TRY();
>> + EXPECT_TRUE(error_caught);
>>
>> This is an anti-pattern for PostgreSQL code. You can't just flush an
>> error without aborting a transaction or subtransaction to recover.
>> Even if it could be shown that this were harmless here, I think it's a
>> terrible idea to have code like this in the tree, as it encourages
>> people to do exactly the wrong thing.
>
> Fair enough, I'll rework it.
>
>> But backing up a step, this also doesn't really seem like the right
>> way to test the error conditions. It deliberately throws away the
>> error message. All this verifies is that you caught an error. If you
>> let the error escape to the client you could have the expected output
>> test that you got the expected message.
>>
>> I think it would be a better idea to structure this as a set of
>> SQL-callable functions and move a bunch of the logic into SQL.
>
> I'll give that approach a try, thanks for the suggestion.
>
> -greg
Robert,
Reworked as indicated, thanks for pointing out the anti-pattern I'd
missed.
best.
-greg
>> --
>> Robert Haas
>> EDB: http://www.enterprisedb.com
v3-0001-Add-a-module-that-tests-Bitmapset.patch
Description: Binary data
