Re: split rm_name and rm_desc out of rmgr.c - Mailing list pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> 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.

Unifying that with this one-source-of-truth seems attractive ...

> 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.

... but I don't especially like that implementation, as it will result
in nonzero code bloat and runtime cost due to replacing all those
constants with global-variable references.  Couldn't you instead set it
up as an enum definition?  Something like

#define PG_RMGR(...)   sym = num,

typedef enum {
#include ...RM_NEXT_ID
} RmgrIds;

#define RM_LAST_ID (RM_NEXT_ID-1)

I'm not actually sure that we need the explicit numbers in the macros
if we do this.  That is, we could just have "#define PG_RMGR(...)   sym,"
and say that the order of the entries in rmgrlist.h is what defines
the manager IDs.  The original coding allowed for gaps in the ID list
but I don't see much value in that.
        regards, tom lane