In Emre Hasegeli's patch for range/inet/geometry opclasses for BRIN, he
chose to move strategy numbers from gist.h to a more central place. He
chose skey.h because that's where btree strategy numbers are defined,
but I'm not sure I agree with that choice.
It's been clear for a while now that these numbers are not gist-only
anyway; spgist and GIN also make use of them, and now brin inclusion
opclass infrastructure also wants to use the same numbers. This is the
reason for a central place, anyway. However, we find datatype specific
definitions in places such as rangetypes.h:
/* Operator strategy numbers used in the GiST and SP-GiST range opclasses */
/* Numbers are chosen to match up operator names with existing usages */
#define RANGESTRAT_BEFORE 1
#define RANGESTRAT_OVERLEFT 2
[ .. etc .. ]
and network_gist.c:
/** Operator strategy numbers used in the GiST inet_ops opclass*/
#define INETSTRAT_OVERLAPS 3
#define INETSTRAT_EQ 18
#define INETSTRAT_NE 19
[ .. etc .. ]
Obviously, the expectation is that the numbers are not needed outside
the opclass implementation itself. I think that's a lost cause, mainly
because we want to have consistent operator names across datatypes.
Therefore I would like to move those numbers elsewhere. Maybe we could
have a new file which would be used only for strategy numbers, such as
src/include/access/stratnum.h, and we would have something like this,
and redefine the ones elsewhere to reference those. For instance,
rangetypes.h could look like this:
/* Operator strategy numbers used in the GiST and SP-GiST range opclasses */
/* Numbers are chosen to match up operator names with existing usages */
#define RANGESTRAT_BEFORE RTLeftStrategyNumber
#define RANGESTRAT_OVERLEFT RTOverLeftStrategyNumber
#define RANGESTRAT_OVERLAPS RTOverlapStrategyNumber
and so on. (I am a bit hesitant about using the "RT" prefix in those
symbols, since the set has grown quite a bit from R-Tree alone. But I
don't have any ideas on what else to use either.)
I can, of course, just leave these files well enough alone and just rely
on the numbers not changing (which surely they won't anyway) and
remaining consistent with numbers used in new opclasses (which surely
they will lest they be born inconsistent with existing ones).
Opinions?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
