Re: splitting *_desc routines - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: splitting *_desc routines
Date
Msg-id CA+U5nMKCGQomExp9hkt5wfViEMrJR07MZK+sLiviibvbAMDtBQ@mail.gmail.com
Whole thread Raw
In response to Re: splitting *_desc routines  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: splitting *_desc routines  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 24 October 2012 21:44, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Here's a small WIP patch that does the proposed splitting.  This is a
> first step towards the objective of having a separately compilable
> xlogdump -- more work is needed before that can be made to work fully.
>
> Now, per previous discussion, I have split each rmgr's desc function
> into its own file.  This is easiest, but it leaves us with several very
> small files in some directories; for example we have
>
> ./src/backend/access/transam/clog_desc.c
> ./src/backend/access/transam/xact_desc.c
> ./src/backend/access/transam/xlog_desc.c
> ./src/backend/access/transam/mxact_desc.c
>
> and also
> ./src/backend/commands/dbase_desc.c
> ./src/backend/commands/seq_desc.c
> ./src/backend/commands/tablespace_desc.c
>
> Is people okay with that, or should we consider merging each subdir's
> files into a single one? (say transam_desc.c and cmds_desc.c).

One file per rmgr is the right level of modularity.

I'd put these in a separate directory to avoid annoyance. Transam is
already too large.

src/backend/access/rmgrdesc/xlog_desc.c
...
src/backend/access/rmgrdesc/seq_desc.c

No difference between commands and other stuff. Just one file per
rmgr, using the rmgr name as listed in rmgr.c


> The other question is whether the function and struct declarations are
> in the best possible locations considering that we will want the files
> to be compilable without a backend environment.  I am using xlogdump as
> a testbed to ensure that everything is kosher (it's not yet there for
> other reasons -- I might end up using something other than
> xlog_internal.h, for example).




-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: proposed community service: make coverage
Next
From: Jan Wieck
Date:
Subject: Re: autovacuum truncate exclusive lock round two