Re: split rm_name and rm_desc out of rmgr.c

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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