Re: GUC names in messages[

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: GUC names in messages[
Дата
Msg-id ZWQVxu8zWIx64V7l@paquier.xyz
обсуждение исходный текст
Ответ на Re: GUC names in messages  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On Mon, Nov 27, 2023 at 01:41:18PM +1100, Peter Smith wrote:
> TBH, I suspect something fishy about these mixed-case GUCs.
>
> In the documentation and in the guc_tables.c they are all described in
> MixedCase (e.g. "DateStyle" instead of "datestyle"), so I felt the
> messages should use the same case the documentation, which is why I
> changed all the ones you are referring to.

FWIW, I've been tempted for a few years to propose that we should keep
the parsers as they behave now, but format the name of these
parameters in the code and the docs to just be lower-case all the
time.

>> Is there a reason why we don't just use islower() or is that just to
>> get something entirely local independent?  I am not sure that it needs
>> to be that complicated.  We should just check that all the characters
>> are lower-case and apply quotes.
>
> Thanks for the feedback. Probably I have overcomplicated it. I'll revisit it.

The use of a static variable with a fixed size was itching me a bit as
well..  I was wondering if it would be cleaner to use %s%s%s in the
strings adding a note that these are GUC names that may be optionally
quoted, then hide what gets assigned in a macro with a result rather
similar to LSN_FORMAT_ARGS (GUC_FORMAT?).  The routine checking if
quotes should be applied would only need to return a boolean to tell
what to do, and could be hidden in the macro.
--
Michael

Вложения

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

Предыдущее
От: "Zhijie Hou (Fujitsu)"
Дата:
Сообщение: RE: Synchronizing slots from primary to standby
Следующее
От: Andrei Lepikhov
Дата:
Сообщение: Re: Postgres picks suboptimal index after building of an extended statistics