On Mon, Apr 8, 2024 at 9:24 AM Kyotaro Horiguchi
<horikyota....@gmail.com> wrote:
> At Mon, 08 Apr 2024 14:46:57 +0900 (JST), Kyotaro Horiguchi 
> <horikyota....@gmail.com> wrote in
> > At Sun, 07 Apr 2024 22:28:06 +0000, Alexander Korotkov 
> > <akorot...@postgresql.org> wrote in
> > > Transform OR clauses to ANY expression
> >
> > This commit introduces a message like this:
> >
> > > gettext_noop("Set the minimum length of the list of OR clauses to attempt 
> > > the OR-to-ANY transformation."),
> >
> > Unlike the usual phrasing of similar messages in this context, which
> > use the form "Sets the minimum length of...", this message uses an
> > imperative form ("Set").  I believe it would be better to align the
> > tone of this message with the others by changing "Set" to "Sets".
> >
> > regards.
> >
> >
> > diff --git a/src/backend/utils/misc/guc_tables.c 
> > b/src/backend/utils/misc/guc_tables.c
> > index 83e3a59d7e..a527ffe0b0 100644
> > --- a/src/backend/utils/misc/guc_tables.c
> > +++ b/src/backend/utils/misc/guc_tables.c
> > @@ -3670,7 +3670,7 @@ struct config_int ConfigureNamesInt[] =
> >
> >       {
> >               {"or_to_any_transform_limit", PGC_USERSET, QUERY_TUNING_OTHER,
> > -                     gettext_noop("Set the minimum length of the list of 
> > OR clauses to attempt the OR-to-ANY transformation."),
> > +                     gettext_noop("Sets the minimum length of the list of 
> > OR clauses to attempt the OR-to-ANY transformation."),
> >                       gettext_noop("Once the limit is reached, the planner 
> > will try to replace expression like "
> >                                                "'x=c1 OR x=c2 ..' to the 
> > expression 'x = ANY(ARRAY[c1,c2,..])'"),
> >                       GUC_EXPLAIN
>
> Sorry for the sequential posts, but I found the following contruct in
> the same patch to be quite untranslatable.

No worries.  But these are distinct patches.

> > errmsg("%s bound of partition \"%s\" is %s %s bound of split partition",
> >               first ? "lower" : "upper",
> >               relname,
> >               defaultPart ? (first ? "less than" : "greater than") : "not 
> > equals to",
> >               first ? "lower" : "upper"),
> >       parser_errposition(pstate, datum->location)));
>
> I might be misunderstanding this, but if the expressions are correct,
> the message could be divided into four fixed messages based on "first"
> and "defaultPart".  Alternatively, it might be better to provide
> simpler explation of the situation.

Yes, splitting this into multiple messages helps both translating and
readability.  Will be fixed in the next couple of days.

------
Regards,
Alexander Korotkov


Reply via email to