Re: Replace magic numbers with strategy numbers for B-tree indexes

From: Daniil Davydov <3danissimo(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replace magic numbers with strategy numbers for B-tree indexes
Date: 2025-07-03 07:50:59
Message-ID: CAJDiXgiARBies04LctRYHyTm++OBt4ViFSbeff4zDB=1pYj48A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Jul 2, 2025 at 6:24 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 30.06.25 05:21, Daniil Davydov wrote:
> > Hi,
> > I noticed that some asserts and cycles use magic numbers 1 and 0
> > instead of BTLessStrategyNumber and InvalidStrategy.
> > At the same time, the BTMaxStrategyNumber macro is used there.
> > I suggest using appropriate macros for 1 and 0 values.
>
> This code, both the original and your changes, make a lot of assumptions
> about the btree strategy numbers, such as that BTLessStrategyNumber is
> the smallest valid one, that InvalidStrategy is smaller than all of
> them, and that all numbers between the smallest and BTMaxStrategyNumber
> are assigned.
>
> However, some of the code actually does require that, because it fills
> in array fields for consecutive strategy numbers. So hiding that fact
> by changing 1 to BTLessStrategyNumber introduces more mystery.
>

Thanks for looking into it!

OK, I can agree that the assumption that InvalidStrategy has the
smallest value is a bit too rough.

But BTLessStrategyNumber and BTMaxStrategyNumber literally say that
these are the min/max numbers.
Thus, assertions like "strategynum >= BTLessStrategyNumber" makes much
more sense than "strategynum >= 1"
(especially when the comment says something like "Check that only
allowed strategy numbers exist") and it is easier to maintain.

The same goes for cycles like [BTLessStrategyNumber;
BTMaxStrategyNumber] and [1; BTMaxStrategyNumber].
All arrays working with strategy numbers are initializing with
BTMaxStrategyNumber elements, so we cannot get any error here.
And if we init an array with length = BTMaxStrategyNumber, we must
assume that all numbers are assigned.
Otherwise, I don't understand why we should have "holes" in the numbering?

I still think that we should get rid of magic numbers.
As a compromise, I'm not replacing 0 with Invalid in the second
version of the patch.

What do you think?

--
Best regards,
Daniil Davydov

Attachment Content-Type Size
v2-0001-Get-rid-of-magic-numbers.patch text/x-patch 3.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-03 08:19:52 Re: Inconsistent LSN format in pg_waldump output
Previous Message Michael Paquier 2025-07-03 07:37:04 Re: Standardize the definition of the subtype field of AlterDomainStmt