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
