Re: splitting *_desc routines

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: splitting *_desc routines
Date: 2012-10-25 08:25:34
Message-ID: CA+U5nMKCGQomExp9hkt5wfViEMrJR07MZK+sLiviibvbAMDtBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24 October 2012 21:44, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2012-10-25 13:04:39 Re: autovacuum truncate exclusive lock round two
Previous Message Amit Kapila 2012-10-25 06:07:21 Re: proposed community service: make coverage