Re: initdb's -c option behaves wrong way?

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: initdb's -c option behaves wrong way?
Дата
Msg-id 2FC1625E-4757-4076-8965-7DBDA5ECC6D9@yesql.se
обсуждение исходный текст
Ответ на Re: initdb's -c option behaves wrong way?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: initdb's -c option behaves wrong way?
Список pgsql-hackers
> On 17 Jan 2024, at 21:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> However ... I don't like the patch much.  It seems to have left
>> the code in a rather random state.  Why, for example, didn't you
>> keep all the code that constructs the "newline" value together?
>
> After thinking about it a bit more, I don't see why you didn't just
> s/strncmp/strncasecmp/ and call it good.  The messiness seems to be
> a result of your choice to replace the GUC's case as shown in the
> file with the case used on the command line, which is not better
> IMO.  We don't change our mind about the canonical spelling of a
> GUC because somebody varied the case in a SET command.

The original patch was preserving the case of the file throwing away the case
from the commandline.  The attached is a slimmed down version which only moves
the assembly of newline to the different cases (replace vs.  new) keeping the
rest of the code intact.  Keeping it in one place gets sort of messy too since
it needs to use different values for a replacement and a new variable.  Not
sure if there is a cleaner approach?

--
Daniel Gustafsson


Вложения

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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Emit fewer vacuum records by reaping removable tuples during pruning
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Emit fewer vacuum records by reaping removable tuples during pruning