Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQCaz-00HEhd-KV for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jan 2024 20:33:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rQCay-00FUKm-Jk for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jan 2024 20:33:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQCay-00FUKe-AH for pgsql-hackers@lists.postgresql.org; Wed, 17 Jan 2024 20:33:08 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQCav-0022WY-Q4 for pgsql-hackers@lists.postgresql.org; Wed, 17 Jan 2024 20:33:06 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 40HKX2O82063811; Wed, 17 Jan 2024 15:33:02 -0500 From: Tom Lane To: Daniel Gustafsson cc: Robert Haas , Alvaro Herrera , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org Subject: Re: initdb's -c option behaves wrong way? In-reply-to: <2062980.1705523170@sss.pgh.pa.us> References: <202401171615.uzdmkozzvo6x@alvherre.pgsql> <2040188.1705511127@sss.pgh.pa.us> <5DFF3111-8ECA-4EF5-B614-9A4C9FAB29BC@yesql.se> <2062980.1705523170@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 17 Jan 2024 15:26:10 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2063809.1705523582.1@sss.pgh.pa.us> Date: Wed, 17 Jan 2024 15:33:02 -0500 Message-ID: <2063810.1705523582@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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