Re: Fixing warnings in back branches?

On Mon, Dec 14, 2015 at 10:06 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-12-14 09:43:07 -0500, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> > On 2015-12-14 10:55:05 +0000, Greg Stark wrote:
>> >> Perhaps just adding some -Wno-* flags would make more sense than
>> >> changing code and possibly introducing bugs.
>>
>> > I think that's a case-by-case decision. Just verbatimly backpatching
>> > something that stewed in master for a year or two seems fine. That's imo
>> > often preferrable because often it's just that existing warning
>> > categories grew more "vigilant", or however you want to describe it. So
>> > if you disable those, you also remove coverage...
>>
>> Meh. If we thought that anything like that was an actual bug, we should
>> have back-patched the fix when removing the warning in HEAD. So I would
>> expect that all remaining warnings are just compiler nannyism, and thus
>> that fixing them is more likely to introduce bugs than do anything very
>> useful.
>
> I'm more concerned about removing warnings that help detect problems
> when backpatching. Right now I need
> -Wno-incompatible-pointer-types \
> -Wno-type-limits \
> -Wno-unused-but-set-variable \
> -Wno-empty-body \
> -Wno-address
>
> to compile 9.1 without warnings. -Wincompatible-pointer-types is quite
> useful to detect problems. The rest indeed is pretty 'Meh'.

IIUC, the main thing that causes incompatible pointer type warnings on
9.1 is the conflation of FILE with gzFile in pg_dump and
pg_basebackup. Not sure exactly which commits fixed that offhand.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company