On Mon, Sep 5, 2011 at 6:56 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Bruce Momjian's message of sáb sep 03 20:18:47 -0300 2011: >> FYI, here are all the C files with over 6k lines: >> >> - 45133 ./interfaces/ecpg/preproc/preproc.c >> - 33651 ./backend/parser/gram.c >> - 17551 ./backend/parser/scan.c >> 14209 ./bin/pg_dump/pg_dump.c >> 10590 ./backend/access/transam/xlog.c >> 9764 ./backend/commands/tablecmds.c >> 8681 ./backend/utils/misc/guc.c >> - 7667 ./bin/psql/psqlscan.c >> 7213 ./backend/utils/adt/ruleutils.c >> 6814 ./backend/utils/adt/selfuncs.c >> 6176 ./backend/utils/adt/numeric.c >> 6030 ./pl/plpgsql/src/pl_exec.c >> >> I have dash-marked the files that are computer-generated. It seems >> pg_dump.c and xlog.c should be split into smaller C files. > > I don't think there's any particular point to this general exercise (too > large for what?), but Simon had patches (or at least ideas) to split > xlog.c IIRC.
Yeah. xlog.c and pg_dump.c are really pretty horrible code, and could probably benefit from being split up. Actually, just splitting them up probably isn't enough: I think they need extensive refactoring. For example, ISTM that StartupXLOG() should delegate substantial chunks of what it does to subroutines, so that the toplevel function is short enough to read and understand without getting lost. On the other hand, I can't help but think splitting up numeric.c would be a bad idea all around. There's not really going to be any coherent way of dividing up the functionality in that file, and it would hinder the ability to make functions static and keep interfaces private. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
