Re: Enabling frontend-only xlog "desc" routines

On Wednesday, November 28, 2012 12:17 AM Alvaro Herrera wrote:
> I mentioned the remaining issues in a previous email (see message-id
> 20121025161751.GE6442@alvh.no-ip.org).  Attached is a patch that enables
> xlogdump to #include xlog_internal.h by way of removing that file's
> inclusion of fmgr.h, which is problematic.  I don't think this should be
> too contentious.

I have tried to go through Xlogdump patch provided in mail chain of
message-id provided.
It seems there is no appropriate file/function header which makes it little
difficult to understand the purpose.
This is just a suggestion and not related to your this mail.
> The other interesting question remaining is what to do about the rm_desc
> function in rmgr.c.  We're split between these two ideas:
> 
> 1. Have this in rmgr.c:
> 
> #ifdef FRONTEND
> #define RMGR_REDO_FUNC(func) NULL
> #else
> #define RMGR_REDO_FUNC(func) func
> #endif /* FRONTEND */
> 
> and then use RMGR_REDO_FUNC() in the table.
> 
> 
> 2. Have this in rmgr.c:
> 
> #ifndef RMGR_REDO_FUNC
> #define RMGR_REDO_FUNC(func) func
> #endif
> 
> And then have the xlogdump Makefile use -D to define a suitable
> RMGR_REDO_FUNC.
> 

What I understood is that as there is only a need of rm_desc function in
xlogdump, so we want to separate it out such that
it can be easily used. 
In Approach-1, define for some of functions (redo, startup, cleanup,..) as
NULL for frontends so that corresponding functions for frontends become
hidden.
In Approach-2, frontend (in this case Xlogdump) need to define value for
that particular Macro by using -D in makefile.

If my above thinking is right, then I think Approach-2 might be better as in
that Frontend will have more flexibility if it wants
to use some other functionality of rmgr. 

With Regards,
Amit Kapila.