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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: initdb's -c option behaves wrong way?
Дата
Msg-id 2062980.1705523170@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: initdb's -c option behaves wrong way?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: initdb's -c option behaves wrong way?
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 17, 2024 at 2:31 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>> Agreed, I think the patch as it stands now where it replaces case insensitive,
>> while keeping the original casing, is the best path forward.  The issue exist
>> in 16 as well so I propose a backpatch to there.

> I like that approach, too. I could go either way on back-patching. It
> doesn't seem important, but it probably won't break anything, either.

We just added this switch in 16, so I think backpatching to keep all
the branches consistent is a good idea.

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?
I'm also unconvinced by the removal of the "assume there's only
one match" break --- if we need to support multiple matches
I doubt that's sufficient.

            regards, tom lane



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Emit fewer vacuum records by reaping removable tuples during pruning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: initdb's -c option behaves wrong way?