On Mon, 10 Jul 2023 at 14:23, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Mon, Jul 10, 2023 at 2:07 PM Kyotaro Horiguchi
> <horikyota....@gmail.com> wrote:
>>
>> At Mon, 10 Jul 2023 09:04:42 +0800, Japin Li <japi...@hotmail.com> wrote in
>> >
>> > On Sat, 08 Jul 2023 at 12:48, Michael Paquier <mich...@paquier.xyz> wrote:
>> > > On Fri, Jul 07, 2023 at 07:23:47PM +0800, Japin Li wrote:
>> > >> +                  appendStringInfoString(&errhint, "\"stderr\"");
>> > >> +#ifdef HAVE_SYSLOG
>> > >> +                  appendStringInfoString(&errhint, ", \"syslog\"");
>> > >> +#endif
>> > >> +#ifdef WIN32
>> > >> +                  appendStringInfoString(&errhint, ", \"eventlog\"");
>> > >> +#endif
>> > >> +                  appendStringInfoString(&errhint, ", \"csvlog\", and 
>> > >> \"jsonlog\"");
>> > >
>> > > Hmm.  Is that OK as a translatable string?
>
> It seems okay to me but needs to be checked.
>
>> >
>> >
>> > Sorry for the late reply!  I'm not sure.  How can I know whether it is 
>> > translatable?
>>
>> At the very least, we can't generate comma-separated lists
>> programatically because punctuation marks vary across languages.
>>
>> One potential approach could involve defining the message for every
>> potential combination, in full length.
>
> Don't we generate a comma-separated list for an error hint of an enum
> parameter? For example, to generate the following error hint:
>
> =# alter system set client_min_messages = 'aaa';
> ERROR:  invalid value for parameter "client_min_messages": "aaa"
> HINT:  Available values: debug5, debug4, debug3, debug2, debug1, log,
> notice, warning, error.
>
> we use the comma-separated generated by config_enum_get_options() and
> do ereport() like:
>
>           ereport(elevel,
>                   (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
>                    errmsg("invalid value for parameter \"%s\": \"%s\"",
>                           name, value),
>                    hintmsg ? errhint("%s", _(hintmsg)) : 0));

> IMO log_destination is a string GUC parameter but its value is the
> list of enums. So it makes sense to me to add a hint message like what
> we do for enum parameters in case where the user mistypes a wrong
> value. I'm not sure why the proposed patch needs to quote the usable
> values, though.

I borrowed the description from pg_settings extra_desc.  In my first patch,
I used the hint message line enum parameter, however, since it might be a
combination of multiple log destinations, so, I update the patch using
extra_desc.

-- 
Regrads,
Japin Li.


Reply via email to