From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Simplifications for error messages related to compression |
Date: | 2022-12-22 05:04:48 |
Message-ID: | Y6PlcHy8CNbq0vvh@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 20, 2022 at 11:12:22PM -0600, Justin Pryzby wrote:
> Yes, and its current users (basebackup) output a gzip file, right ?
>
> pg_dump -Fc doesn't output a gzip file, but now it's using user-facing
> compression specifications referring to it as "gzip".
Not all of them are compressed either, like the base TOC file.
> If you tell someone they can write -Z gzip, they'll be justified in
> expecting to see "gzip" as output.
That's the point where my interpretation is different than yours,
where I don't really see as an issue that we do not generate a gzip
file all the time in the output. Honestly, I am not sure that there
is anything to win here by not using the same option interface for all
the binaries or have tweaks to make pg_dump cope with that (like using
zlib as an extra alias). The custom, directory and tar formats of
pg_dumps have their own idea of the files to compress or not (like
the base TOC file is never compressed so as one can do a pg_restore
-l).
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-12-22 05:36:58 | Re: psql tab-complete |
Previous Message | Bharath Rupireddy | 2022-12-22 04:39:23 | Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures |