Обсуждение: strings: ".. (compression)? is not supported by this build"

$ git grep 'is not supported by this build' '*c'
src/backend/access/transam/xloginsert.c:                                                elog(ERROR, "LZ4 is not
supportedby this build");
 
src/backend/access/transam/xloginsert.c:                                                elog(ERROR, "zstd is not
supportedby this build");
 
src/backend/access/transam/xloginsert.c:                        elog(ERROR, "LZ4 is not supported by this build");
src/backend/access/transam/xloginsert.c:                        elog(ERROR, "zstd is not supported by this build");
...
src/backend/replication/basebackup_gzip.c:                       errmsg("gzip compression is not supported by this
build")));
src/backend/replication/basebackup_lz4.c:                        errmsg("lz4 compression is not supported by this
build")));
src/backend/replication/basebackup_zstd.c:                       errmsg("zstd compression is not supported by this
build")));

Should the word "compression" be removed from basebackup, for consistency with
the use in xloginsert.c ?  And "lz4" capitalization changed for consistency (in
one direction or the other).  See 4035cd5d4, e9537321a7, 7cf085f07.  Maybe zstd
should also be changed to Zstandard per 586955ddd.

To avoid the extra translation, and allow the compiler to merge strings.

The "binary size" argument wouldn't apply, but note that pg_dump uses this
language:

src/bin/pg_dump/compress_io.c:          pg_fatal("not built with zlib support");

See also some other string messages I mentioned here:
https://www.postgresql.org/message-id/20210622001927.GE29179@telsasoft.com
|+#define NO_LZ4_SUPPORT() \
|+       ereport(ERROR, \
|+                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), \
|+                        errmsg("unsupported LZ4 compression method"), \
|+                        errdetail("This functionality requires the server to be built with lz4 support."), \
|+                        errhint("You need to rebuild PostgreSQL using --with-lz4.")))
|
|src/bin/pg_dump/pg_backup_archiver.c:                           fatal("cannot restore from compressed archive
(compressionnot supported in this installation)");
 
|src/bin/pg_dump/pg_backup_archiver.c:           pg_log_warning("archive is compressed, but this installation does not
supportcompression -- no data will be available");
 
|src/bin/pg_dump/pg_dump.c:              pg_log_warning("requested compression not available in this installation --
archivewill be uncompressed");
 

-- 
Justin

On Wed, Jul 13, 2022 at 10:33 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> $ git grep 'is not supported by this build' '*c'
> src/backend/access/transam/xloginsert.c:                                                elog(ERROR, "LZ4 is not
supportedby this build");
 
> src/backend/access/transam/xloginsert.c:                                                elog(ERROR, "zstd is not
supportedby this build");
 
> src/backend/access/transam/xloginsert.c:                        elog(ERROR, "LZ4 is not supported by this build");
> src/backend/access/transam/xloginsert.c:                        elog(ERROR, "zstd is not supported by this build");
> ...
> src/backend/replication/basebackup_gzip.c:                       errmsg("gzip compression is not supported by this
build")));
> src/backend/replication/basebackup_lz4.c:                        errmsg("lz4 compression is not supported by this
build")));
> src/backend/replication/basebackup_zstd.c:                       errmsg("zstd compression is not supported by this
build")));
>
> Should the word "compression" be removed from basebackup, for consistency with
> the use in xloginsert.c ?  And "lz4" capitalization changed for consistency (in
> one direction or the other).  See 4035cd5d4, e9537321a7, 7cf085f07.  Maybe zstd
> should also be changed to Zstandard per 586955ddd.
>
> To avoid the extra translation, and allow the compiler to merge strings.

Translation isn't an issue here because the first group of messages
are reported using elog(), not ereport(). There is something to be
said for being consistent, though.

I feel like it's kind of awkward that this thing is named Zstandard
but the library is libzstd and the package name is probably also zstd.
I worry a bit that if we make the messages say zstandard instead of
zstd it makes it harder to figure out. It's probably not a huge issue,
though.

-- 
Robert Haas
EDB: http://www.enterprisedb.com