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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Robert Haas <robertmhaas@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
pgsql-hackers@lists.postgresql.org
Date: 2024-01-19T16:33:57Z
Lists: pgsql-hackers
Attachments
- v4-0001-Make-initdb-c-option-case-insensitive.patch (text/x-diff) patch v4-0001
Daniel Gustafsson <daniel@yesql.se> writes: > I'll give some more time for opinions, then I'll go ahead with one of the > patches with a backpatch to v16. OK, I take back my previous complaint that just using strncasecmp would be enough --- I was misremembering how the code worked, and you're right that it would use the spelling from the command line rather than that from the file. However, the v3 patch is flat broken. You can't assume you have found a match until you've verified that whitespace and '=' appear next --- otherwise, you'll be fooled by a guc_name that is a prefix of one that appears in the file. I think the simplest change that does it correctly is as attached. Now, since I was the one who wrote the existing code, I freely concede that I may have too high an opinion of its readability. Maybe some larger refactoring is appropriate. But I didn't find that what you'd done improved the readability. I'd still rather keep the newline-assembly code together as much as possible. Maybe we should do the search part before we build any of newline? regards, tom lane
Commits
-
Fix initdb's -c option to treat the GUC name case-insensitively.
- fce2ce797c41 17.0 landed
- b78f4d22b2f2 16.3 landed