Re: Replace magic numbers with strategy numbers for B-tree indexes
От | Michael Paquier |
---|---|
Тема | Re: Replace magic numbers with strategy numbers for B-tree indexes |
Дата | |
Msg-id | aLYxeYIY70jup555@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Replace magic numbers with strategy numbers for B-tree indexes (Daniil Davydov <3danissimo@gmail.com>) |
Список | pgsql-hackers |
On Mon, Sep 01, 2025 at 09:04:04PM +0700, Daniil Davydov wrote: > I don't think that we can just create different enums for each index strategies. > We have (for example) ScanKey functionality, which can work with different > indexes (and such a functions has a uint16 argument for strategy number). > > Or are you talking about a single huge enum for all index types? I don't > mind trying to do something like this, but I'm not sure how > "beautiful" it will be. +typedef enum BTStrategy +{ + BTInvalidStrategy, + BTLessStrategy, + BTLessEqualStrategy, + BTEqualStrategy, + BTGreaterEqualStrategy, + BTGreaterStrategy, + BTNumOfStrategies +} BTStrategy; [...] - List *btree_clauses[BTMaxStrategyNumber + 1], + List *btree_clauses[BTNumOfStrategies], Isn't that where you'd want to introduce a separate #define to track the maximum number in the enum? Adding the total number inside BTStrategy would be wrong IMO. Anyway, the advantage of an enum is also to be able to initialize the first value, with the next one following suit. With most of the code using the strategy numbers in for loops, we are not taking advantage of an enum structure, which is relevant for example to find paths with switch/case without default, where compilers would warn about missing values. A second one would be type enforcement in dedicated APIs, and we already have StrategyNumber for this job in ScanKeyInit(), for example. +/* Static inline function check */ +static inline bool BTStrategyIsValidFunc(uint16 strat) +{ + switch(strat) Note that this is used nowhere :) -- Michael
Вложения
В списке pgsql-hackers по дате отправления: