From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: clean up obsolete initdb locale handling
In-reply-to: <27394.1565276193@sss.pgh.pa.us>
References: <eeaf2f99-a1a6-8aca-3f43-9ab0b2fb112a@2ndquadrant.com>
 <27394.1565276193@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 08 Aug 2019 10:56:33 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30433.1565279505.1@sss.pgh.pa.us>
Date: Thu, 08 Aug 2019 11:51:45 -0400
Message-ID: <30434.1565279505@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> ... In particular, I'm concerned that this patch will
> result in subtle changes in what settings get chosen during initdb.

OK, after reviewing the code a bit more I take that back --- initdb's
choices are entirely made within initdb.

However, I don't much like the choice to set LC_COLLATE and LC_CTYPE
differently.  That seems to be risking weird behavior, and for what?
I'd be inclined to just remove the WIN32 stanza, initialize all
three of these variables with "", and explain it along the lines of

    * In the postmaster, absorb the environment values for LC_COLLATE
    * and LC_CTYPE.  Individual backends will change these later to
    * settings taken from pg_database, but the postmaster cannot do
    * that.  If we leave these set to "C" then message localization
    * might not work well in the postmaster.

That ends up being no code change in main.c, except on Windows.
I concur that we can drop the transmission of LC_COLLATE and
LC_CTYPE via environment variables.

			regards, tom lane