Обсуждение: clean up obsolete initdb locale handling

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.

The attached patch cleans that up.  (Not totally sure about the WIN32
block, but the change seems good to me.)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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

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

On 2019-08-08 17:51, Tom Lane wrote:
> 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.

OK, let's do it like that.  Updated patch attached.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> OK, let's do it like that.  Updated patch attached.

LGTM, but I don't have the ability to test it on Windows.

            regards, tom lane

On 2019-08-12 20:17, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> OK, let's do it like that.  Updated patch attached.
> 
> LGTM, but I don't have the ability to test it on Windows.

Committed, after some testing on Windows.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services