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