Re: GUC names in messages

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: GUC names in messages
Дата
Msg-id aaa89c5c-7921-49cb-a939-45206c6fe289@eisentraut.org
обсуждение исходный текст
Ответ на Re: GUC names in messages  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: GUC names in messages  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: GUC names in messages  (Daniel Gustafsson <daniel@yesql.se>)
Re: GUC names in messages  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On 04.01.24 07:53, Peter Smith wrote:
>> Now that I read this again, I think this is wrong.
>>
>> We should decide the quoting for a category, not the actual content.
>> Like, quote all file names; do not quote keywords.
>>
>> This led to the attempted patch to decide the quoting of GUC parameter
>> names dynamically based on the actual content, which no one really
>> liked.  But then, to preserve consistency, we also need to be uniform in
>> quoting GUC parameter names where the name is hardcoded.
>>
> 
> I agree. By attempting to define when to and when not to use quotes it
> has become overcomplicated.
> 
> Earlier in the thread, I counted how quotes were used in the existing
> messages [5]; there were ~39 quoted and 164 not quoted. Based on that
> we chose to stay with the majority, and leave all the unquoted ones so
> only adding quotes "when necessary". In hindsight, that was probably
> the wrong choice because it opened a can of worms about what "when
> necessary" even means (e.g. what about underscores, mixed case etc).
> 
> Certainly one simple rule "just quote everything" is easiest to follow.

I've been going through the translation updates for PG17 these days and 
was led back around to this issue.  It seems we left it in an 
intermediate state that no one was really happy with and which is 
arguably as inconsistent or more so than before.

I think we should accept your two patches

v6-0001-GUC-names-docs.patch
v6-0002-GUC-names-add-quotes.patch

which effectively everyone was in favor of and which seem to be the most 
robust and sustainable solution.

(The remaining three patches from the v6 set would be PG18 material at 
this point.)




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

Предыдущее
От: Robins Tharakan
Дата:
Сообщение: Re: Why is parula failing?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Adding the extension name to EData / log_line_prefix