Re: Large C files
От | Robert Haas |
---|---|
Тема | Re: Large C files |
Дата | |
Msg-id | CA+TgmoZq6Wks6CijUKfE7zN3kHmqDfn6f39oYyQp0HR1BNaH5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Large C files (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Large C files
|
Список | pgsql-hackers |
On Tue, Sep 6, 2011 at 9:14 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 7 September 2011 01:18, Bruce Momjian <bruce@momjian.us> wrote: >> I am confused how moving a function from one C file to another could >> cause breakage? > > I'm really concerned about silent breakage, however unlikely - that is > also Simon and Robert's concern, and rightly so. If it's possible in > principle to guard against a certain type of problem, we should do so. > While this is a mechanical process, it isn't quite that mechanical a > process - I would not expect this work to be strictly limited to > simply spreading some functions around different files. Certainly, if > there are any other factors at all that could disrupt things, a > problem that does not cause a compiler warning or error is vastly more > troublesome than one that does, and the most plausible such error is > if a symbol is somehow resolved differently when the function is > moved. I suppose that the simplest way that this could happen is > probably by somehow having a variable of the same name and type appear > twice, once as a static, the other time as a global. > > IMHO, when manipulating code at this sort of macro scale, it's good to > be paranoid and exhaustive, particularly when it doesn't cost you > anything anyway. Unlike when writing or fixing a bit of code at a > time, which we're all used to, if the compiler doesn't tell you about > it, your chances of catching the problem before a bug manifests itself > are close to zero. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: