Skip site navigation (1) Skip section navigation (2)

Re: initdb stores default client_encoding from environment-variable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Wolfgang(dot)Koenig" <Wolfgang(dot)Koenig(at)versatel(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org, "Olaf(dot)Waldheim" <Olaf(dot)Waldheim(at)versatel(dot)de>
Subject: Re: initdb stores default client_encoding from environment-variable
Date: 2010-04-15 02:03:32
Message-ID: 20509.1271297012@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Wolfgang.Koenig" <Wolfgang(dot)Koenig(at)versatel(dot)de> writes:
> initdb stores default client_encoding from environment-variable
> Postgres Version: 8.4.3 and 8.3.6
> Operating System: Sun Solaris 5.10 and SuseEnterprise 9

> When a database is initialized with the initdb-command, the default
> client_enconding, which will be stored in the DB, depends on the value
> of the environment-variable PGCLIENTENCODING at the time of running
> initdb.

Hmm, it doesn't do that for me.  initdb actually takes some pains to
ensure that PGCLIENTENCODING doesn't affect it:

	/* Also ensure backend isn't confused by this environment var: */
	unsetenv("PGCLIENTENCODING");

I suppose that unsetenv isn't working properly on your platform for some
reason.  Does configure think that it's present?  If not, we're going to
fall back to the implementation in src/port/unsetenv.c, which might not
work for you.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2010-04-15 02:13:16
Subject: Re: Reset ACL to default for pg 8.0
Previous:From: Bruce MomjianDate: 2010-04-15 01:59:39
Subject: Re: build error: strlcat/strlcpy used from heimdal libroken.so

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group