Re: [HACKERS] freefuncs.c is never called from anywhere!?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] freefuncs.c is never called from anywhere!? |
Дата | |
Msg-id | 9901.949333324@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] freefuncs.c is never called from anywhere!? (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Ответы |
Re: [HACKERS] freefuncs.c is never called from anywhere!?
|
Список | pgsql-hackers |
Peter Eisentraut <e99re41@DoCS.UU.SE> writes: >>>> Please no more _deadcode. Why do we have CVS? > I *suspect* the purpose of some of these sections is that if it turns out > somebody needed them for their application, we could just tell them to > re-enable them there and there. I think there are several different motivations, and it would be bad to tar all the occurrences of NOT_USED with the same brush. Some of them are indeed just code that was #ifdef'd out while testing a replacement solution, and never physically removed. I think that's what CVS is for; we should keep history in CVS versions, not in the current sources. Some of them are useful code that just happens not to be referenced at the moment, but might be needed again at any time. (And who'd think to go look in back CVS versions, when wondering "is there a routine that ..."?) Some of them are code that was disabled because it was broken, but with hopes of fixing and re-enabling it someday. (The expensive-function code in the optimizer seems to be an example of this.) The advantage of leaving such code in current sources is that it has a better chance of tracking global edits, such as routine or struct field renamings. I know that I have usually ignored files in _deadcode directories when making widespread changes, which means that those files drift further and further away from any hope of future usefulness. This doesn't happen quite as fast for code that's #ifdef NOT_USED but still present in current source files. I think it would be a bad idea to go around and yank out NOT_USED code wholesale --- this should be looked at on a case-by-case basis, with consideration of whether the code might be useful again in future. But I think I might vote for pruning the _deadcode directories wholesale. I suspect the files in them are suffering from irrecoverable bit rot. regards, tom lane
В списке pgsql-hackers по дате отправления: