Re: Some leftovers of recent message cleanup?

At Fri, 20 Aug 2021 19:36:02 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2021/08/20 11:53, Kyotaro Horiguchi wrote:
> > At Thu, 19 Aug 2021 20:29:42 +0900, Fujii Masao
> > <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
> >> On 2021/08/19 17:03, Kyotaro Horiguchi wrote:
> >>> Hello.
> >>> While I was examining message translation for PG14, I found some
> >>> messages that would need to be fixed.
> >>> 0001 is a fix for perhaps-leftovers of the recent message cleanups
> >>> related to "positive integer"(fd90f6ba7a).
> >>
> >> There are still other many messages using "positive" and "negative"
> >> keywords.
> >> We should also fix them at all?
> > I'm not sure, or no if anything. My main point here is not to avoid
> > use of such kind of words, but reducing variations of the effectively
> > the same message from the view of translator burden. The two messages
> > in 0001 are in that category. I noticed those messages accidentally. I
> > don't think they are the only instance of such divergence, but I'm not
> > going to do a comprehensive examination of such divergences.. (Or do I
> > need to check that more comprehensively?)
>
>
> Understood.
>
> - errmsg("modulus for hash partition must be a positive
> - integer")));
> + errmsg("modulus for hash partition must be an integer greater than
> zero")));
>
> "an integer greater" should be "an integer value greater" because
> we use that words in other similar log messages like "modulus for
> hash partition must be an integer value greater than zero"
> in src/backend/partitioning/partbounds.c?

Ugh... Of course. I thought I did that way but the actual file is
incorrect... Fixed that in the attached.

> I'm thinking to back-patch this to v11 where hash partitioning
> was supported. On the other hand, the following change should

If I'm not missing something, back to 13, where the "word change" took
place? For 11 and 12, we need to change the *both* messages.

v11, 12
./src/backend/parser/parse_utilcmd.c3744: errmsg("modulus for hash partition must be a positive integer")));
Binary file ./src/backend/parser/gram.o matches
./src/backend/partitioning/partbounds.c2086: errmsg("modulus for hash partition must be a positive integer")));

v13, 14
./src/backend/parser/parse_utilcmd.c3942: errmsg("modulus for hash partition must be a positive integer")));
./src/backend/partitioning/partbounds.c4640: errmsg("modulus for hash partition must be an integer value greater than zero")));

> be back-patched to all supported versions.
>
> - errmsg("distance in phrase operator should not be
> - greater than %d",
> + errmsg("distance in phrase operator must be an integer value between
> zero and %d inclusive",

The message is inconsistent since before the "postive" patch^^;

v10, 11, 12
./src/backend/utils/adt/tsquery.c200: errmsg("distance in phrase operator should not be greater than %d",
./src/backend/utils/adt/tsquery_op.c123: errmsg("distance in phrase operator should be non-negative and less than %d",

v13,14
./src/backend/utils/adt/tsquery.c200: errmsg("distance in phrase operator should not be greater than %d",
./src/backend/utils/adt/tsquery_op.c124: errmsg("distance in phrase operator must be an integer value between zero and %d inclusive",

So this patch is meaningful only for v13 and later, too. Not sure what
to do for v12 and earlier but doesn't seem to be in much necessity.

--
Kyotaro Horiguchi
NTT Open Source Software Center