Re: splitting *_desc routines

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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-24 20:44:35
Message-ID: 20121024204435.GI6853@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).

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).

Once we settle these issues, I will finish up the patch by adding nice
file header comments and the like.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
splitdesc.patch text/x-diff 74.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2012-10-24 22:20:40 Re: autovacuum truncate exclusive lock round two
Previous Message Jan Wieck 2012-10-24 20:20:38 autovacuum truncate exclusive lock round two