On Tue, Dec 20, 2022 at 08:29:32PM -0600, Justin Pryzby wrote: > - pg_fatal("not built with zlib support"); > + pg_fatal("this build does not support compression > with %s", "gzip"); > > I tried to say in the other thread that gzip != zlib. > > This message may be better for translation, but (for WriteDataToArchive > et al) the message is now less accurate, and I suspect will cause some > confusion.
Compression specifications use this term, so, like bbstreamer_gzip.c, that does not sound like a big difference to me as everything depends on HAVE_LIBZ, still we use gzip for all the user-facing terms. > 5e73a6048 introduced a similar user-facing issue: pg_dump -Fc -Z gzip > does not output a gzip. We've never mentioned any compression method in the past docs, just that things can be compressed. > $ ./tmp_install/usr/local/pgsql/bin/pg_dump -h /tmp -Fc -Z gzip regression > |xxd |head > 00000000: 5047 444d 5001 0e00 0408 0101 0100 0000 PGDMP........... > > I'm okay with it if you think this is no problem - maybe it's enough to > document that the output is zlib and not gzip. Perhaps. > Otherwise, one idea was to reject "gzip" with -Fc. It could accept > integers only. I am not sure what we would gain by doing that, except complications with the code surrounding the handling of compression specifications, which is a backward-compatible thing as it can handle integer-only inputs. > BTW I think it's helpful to include the existing participants when > forking a thread. Err, okay.. Sorry about that. -- Michael
signature.asc
Description: PGP signature