Re: splitting *_desc routines
От | Simon Riggs |
---|---|
Тема | Re: splitting *_desc routines |
Дата | |
Msg-id | CA+U5nMKCGQomExp9hkt5wfViEMrJR07MZK+sLiviibvbAMDtBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: splitting *_desc routines (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: splitting *_desc routines
|
Список | 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 по дате отправления: