From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: split rm_name and rm_desc out of rmgr.c |
Date: | 2013-02-05 16:37:34 |
Message-ID: | 20130205163734.GD5753@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
split-rm_desc-3.patch | text/x-diff | 3.6 KB |
split-rm_desc-3a.patch | text/x-diff | 5.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2013-02-05 16:38:42 | Re: Visual Studio 2012 RC |
Previous Message | Andrew Dunstan | 2013-02-05 16:34:26 | Re: Visual Studio 2012 RC |