Re: incompatible pointer types with newer zlib

On fre, 2012-02-24 at 11:10 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On tor, 2012-02-23 at 10:17 -0500, Tom Lane wrote:
> >> void * seems entirely reasonable given the two different usages, but
> >> I would be happier if the patch added explicit casts whereever FH is
> >> set to or used as one of these two types.
>
> > That would add about 70 casts all over the place. I don't think that
> > will make things clearer or more robust. I think we either leave it as
> > my first patch for now or find a more robust solution with a union or
> > something.
>
> Hm. Could we just create two separate fields? It's not real clear to
> me that forcing both these usages into a generic pointer buys much.

It's used in confusing ways.

In pg_backup_files.c _PrintFileData(), it's a compile-time decision
whether FH is a FILE or a gzFile:

#ifdef HAVE_LIBZ
AH->FH = gzopen(filename, "rb");
#else
AH->FH = fopen(filename, PG_BINARY_R);
#endif

But if we changed FH to be gzFile under HAVE_LIBZ, then tons of other
places will complain that use fread(), fwrite(), fileno(), etc. directly
on FH.

Considering the volume of who complains in one way versus the other, I
think _PrintFileData() is at fault.

I think the best fix would be to rearrange _PrintFileData() so that it
doesn't use FH at all. Instead, we could define a separate
ArchiveHandle field IF that works more like OF, and then change
ahwrite() to use that.