Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended - Mailing list pgsql-hackers

On Wed, Oct 8, 2025 at 7:01 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2025-Oct-09, David Rowley wrote:
>
> > On Thu, 9 Oct 2025 at 00:36, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > > Yeah, that change makes sense to me.  With an eye towards not forcing
> > > the translators to understand the message context or forced to translate
> > > the word "parallel", I would suggest to take the option name out of the
> > > sentence, maybe something like
> > >
> > >   value for VACUUM option \"%s\" must be between 0 and %d
> >
> > Just looking at the other error messages. They all seems to put the
> > option in upper case but not in quotes. Following along with those,
> > we'd end up with:
> >
> > PARALLEL option must be between 0 and %d
> >
> > Would that be enough to help the translator understand not to
> > translate the option name?
>
> This works for me, yeah.  Though I'd still do "%s option must be between
> 0 and %d" (ie. make the option a separate string) and then they don't
> need to understand that -- and also if there's another option elsewhere
> whose value needs to be "between 0 and %d", then this string can be
> reused.

+1 to using "%s" instead of hardcoding "PARALLEL" in the message.

I noticed we're currently hardcoding the "BUFFER_USAGE_LIMIT" option
name in the error message:

ereport(ERROR,
         (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
          errmsg("BUFFER_USAGE_LIMIT option must be 0 or between %d kB
and %d kB",
                 MIN_BAS_VAC_RING_SIZE_KB, MAX_BAS_VAC_RING_SIZE_KB),
          hintmsg ? errhint("%s", _(hintmsg)) : 0));

Should we also change this for consistency with how we handle other
VACUUM options?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com