Tom Lane wrote:
> Couldn't we do something similar to the design for SQL keyword constants,
> wherein the actual data is in macros in a header file (providing exactly
> one source of truth for each RM) and then various .c files can #include
> that after #defining the macro as they need?
Here are two patches implementing this idea. The first one is simpler
and just replaces the table in rmgr.c with an appropriate PG_RMGR
define.
The second one touches rmgr.h as well. That file currently has a list
of #defines with symbolic rmgr names and their numeric IDs. The
approach in the second patch is to turn these into "extern const RmgrId"
instead, and use a second inclusion of rmgrlist.h in rmgr.c that assigns
them the values as consts. This has the disadvantage that the array
size RM_MAX_ID cannot use the symbolic RM_SPGIST_ID value, but instead
it needs a literal "16". Otherwise the compile complains:
error: variably modified ‘RmgrTable’ at file scope
I am not too sure about that second change. However, I'm a bit uneasy
about leaving a second list of rmgrs around; since we're creating what
should be the canonical list of rmgrs, it makes sense to reduce the two
copies we have. Better ideas for that second list are welcome.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
