Re: initdb's -c option behaves wrong way? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: initdb's -c option behaves wrong way?
Date
Msg-id 2062980.1705523170@sss.pgh.pa.us
Whole thread Raw
In response to Re: initdb's -c option behaves wrong way?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: initdb's -c option behaves wrong way?
List 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 by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning
Next
From: Tom Lane
Date:
Subject: Re: initdb's -c option behaves wrong way?