On Tue, Jan 31, 2023 at 09:00:56AM +0000, gkokolatos@pm.me wrote:
> > In my mind, three things here are misleading, because it doesn't use
> > gzip headers:
> >
> > | GzipCompressorState, DeflateCompressorGzip, "gzip compressed".
> >
> > This comment is about exactly that:
> >
> > * underlying stream. The second API is a wrapper around fopen/gzopen and
> > * friends, providing an interface similar to those, but abstracts away
> > * the possible compression. Both APIs use libz for the compression, but
> > * the second API uses gzip headers, so the resulting files can be easily
> > * manipulated with the gzip utility.
> >
> > AIUI, Michael says that it's fine that the user-facing command-line
> > options use "-Z gzip" (even though the "custom" format doesn't use gzip
> > headers). I'm okay with that, as long as that's discussed/understood.
>
> Thank you for the input Justin. I am currently waiting for input from a
> third person to get some conclusion. I thought that it should be stated
> before my inactiveness is considered as indifference, which is not.
I'm not sure what there is to lose by making the names more accurate -
especially since they're private/internal-only.
Tomas marked himself as a committer, so maybe could comment.
It'd be nice to also come to some conclusion about whether -Fc -Z gzip
is confusing (due to not actually using gzip).
BTW, do you intend to merge this for v16 ? I verified in earlier patch
versions that tests all pass with lz4 as the default compression method.
And checked that gzip output is compatible with before, and that old
dumps restore correctly, and there's no memory leaks or other errors.
--
Justin
