Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
