Re: Large C files

On Mon, Sep 5, 2011 at 6:56 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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