Re: pgsql: Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: pgsql: Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option
Дата
Msg-id CAApHDvrQauwWHFPRWdf=UDWUwWZaCoNHxHwJE3O0kWhNUk7Hqg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Add VACUUM/ANALYZE BUFFER_USAGE_LIMIT option  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-committers
On Tue, 11 Apr 2023 at 18:29, Kyotaro Horiguchi <horikyota.ntt@gmail.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



В списке pgsql-committers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: pgsql: Improve ereports for VACUUM's BUFFER_USAGE_LIMIT option
Следующее
От: David Rowley
Дата:
Сообщение: Re: pgsql: Catalog NOT NULL constraints