Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hvjqN-0003ZL-RT for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Aug 2019 14:56:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hvjqL-00014m-O3 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Aug 2019 14:56:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hvjqL-00014R-Bg for pgsql-hackers@lists.postgresql.org; Thu, 08 Aug 2019 14:56:41 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1hvjqE-00036m-Uu for pgsql-hackers@postgresql.org; Thu, 08 Aug 2019 14:56:40 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x78EuXoB027395; Thu, 8 Aug 2019 10:56:33 -0400 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers Subject: Re: clean up obsolete initdb locale handling In-reply-to: References: Comments: In-reply-to Peter Eisentraut message dated "Thu, 08 Aug 2019 16:27:25 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27393.1565276193.1@sss.pgh.pa.us> Date: Thu, 08 Aug 2019 10:56:33 -0400 Message-ID: <27394.1565276193@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Eisentraut writes: > A long time ago, we changed LC_COLLATE and LC_CTYPE from cluster-wide to > per-database (61d967498802ab86d8897cb3c61740d7e9d712f6). There is some > leftover code from that in initdb.c and backend/main/main.c to pass > these environment variables around in the expectations that the backend > will write them to pg_control during bootstrap, which is of course all a > lie now. Well, the comments' references to pg_control are indeed obsolete, but why wouldn't we just replace that with references to "the appropriate entry in pg_database"? I don't see why that movement changed anything about what should happen here. In particular, I'm concerned that this patch will result in subtle changes in what settings get chosen during initdb. regards, tom lane