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-21 04:52:21 |
Message-ID: | Y6KRBTeer6cqCjRL@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-12-21 05:01:26 | Re: Refactor SCRAM code to dynamically handle hash type and key length |
Previous Message | Andrey Lepikhov | 2022-12-21 04:14:02 | Optimization issue of branching UNION ALL |