From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jan Urbański <wulczer(at)wulczer(dot)org> |
Subject: | Re: Large C files |
Date: | 2011-09-07 18:12:34 |
Message-ID: | 26671.1315419154@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Robert Haas wrote:
>> I was less concerned about the breakage that might be caused by
>> variables acquiring unintended referents - which should be unlikely
>> anyway given reasonable variable naming conventions - and more
>> concerned that the associated refactoring would break recovery. We
>> have no recovery regression tests; that's not a good thing.
> So we are talking about more than moving files between functions? Yes,
> it would be risky to restruction functions, but for someone who
> understand that code, it might be safe.
The pgrminclude-induced bug you just fixed shows a concrete way in which
moving code from one file to another might silently break it, ie, it
still compiles despite lack of definition of some symbol it's intended
to see.
Having said that, I tend to agree that xlog.c is getting so large and
messy that it needs to be broken up. But I'm not in favor of breaking
up files just because they're large, eg, ruleutils.c is not in need of
such treatment. The problem with xlog.c is that it seems to be dealing
with many more considerations than it originally did.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-07 18:21:16 | Re: custom variables and PGC_SUSET issue |
Previous Message | Robert Haas | 2011-09-07 18:07:25 | Re: custom variables and PGC_SUSET issue |