Re: initdb's -c option behaves wrong way?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2024-01-17T20:26:10Z
Lists: 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
Commits
-
Fix initdb's -c option to treat the GUC name case-insensitively.
- fce2ce797c41 17.0 landed
- b78f4d22b2f2 16.3 landed