Re: pgsql: Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org, melanieplageman(at)gmail(dot)com
Subject: Re: pgsql: Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option
Date: 2023-04-11 07:40:47
Message-ID: CAApHDvrQauwWHFPRWdf=UDWUwWZaCoNHxHwJE3O0kWhNUk7Hqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Tue, 11 Apr 2023 at 18:29, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> My point was just that "valid" seems redundant. (Sorry, but..)
> However, looking again, many of the "cases" are like "requires a
> <type> value", which looks womewhat similar to "requires a valid
> value" when the <type> cannot be represented by a word. Some remaining
> example of these "caes" are:
>
> ./commands/define.c 54: errmsg("%s requires a parameter",
> (the "parameter" means the option value for type name)

OK, that makes sense. I see that defGetString() already checks for
NULL args, so it seems better to leave it to that to check for
consistency with other ERROR messages.

I've pushed that plus the uppercasing of buffer_usage_limit that you mentioned.

I additionally adjusted the two remaining ERRORs to become one. I
thought it seemed better to instead of complaining that 'x' is an
invalid value for BUFFER_USAGE_LIMIT, just to go ahead and give more
details about which are valid values.

Thanks for looking at this change and reporting your findings.

David

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message David Rowley 2023-04-11 10:45:45 Re: pgsql: Catalog NOT NULL constraints
Previous Message David Rowley 2023-04-11 07:37:11 pgsql: Improve ereports for VACUUM's BUFFER_USAGE_LIMIT option