Re: Fixing warnings in back branches?

On Tue, Dec 15, 2015 at 11:04:07AM -0500, Robert Haas wrote:
> On Tue, Dec 15, 2015 at 9:17 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2015-12-15 09:09:39 -0500, Tom Lane wrote:
> >> In the end, if you're building an old branch, you should be doing it with
> >> old tools.

I grant that's the most risk-averse choice, because each release probably does
get the most testing with compilers contemporary to its dot-zero release date.
Your statement takes a step beyond neglecting warnings. It is sound advice
for packagers, but it is overkill for the average end user. We don't
emphasize the similar risks that apply to new libc, Perl, kernels, etc. You
have back-patched changes to let new compilers build working/optimal code,
e.g. 649839d and e709807; that's great to continue doing. Acquiring an old
compiler is tedious, and the risk of being the first to encounter a new
miscompilation is low.

> I think that it might be worth back-patching some of the warning fixes
> we've done would be a good idea. Like this one:
>
> - if (!res || !res->cmdStatus || strncmp(res->cmdStatus, "INSERT
> ", 7) != 0)
> + if (!res || strncmp(res->cmdStatus, "INSERT ", 7) != 0)
> return "";
>
> I really don't see how back-patching that can hurt anything, and it
> gets rid of a warning, so great. But not all cases are going to be so
> clear cut, and getting all supported back-branches to compile warning
> free on every contributor's current toolchain sounds like a treadmill
> I don't want to get on.

Agreed. We don't have or need a firm ban on back-branch warning fixes, but
let's continue to cite the low value of contributions having that aim.

nm