Comments on: LANG prevents PostgreSQL initdb http://dan.langille.org/2009/04/17/lang-prevents-postgresql-initdb/ He has another more popular diary. This one is more general. Wed, 08 Feb 2012 00:12:35 +0000 http://wordpress.org/?v=2.5 By: Dan http://dan.langille.org/2009/04/17/lang-prevents-postgresql-initdb/#comment-319 Dan Sat, 18 Apr 2009 13:59:17 +0000 http://dan.langille.org/?p=236#comment-319 Yes, ~pgsql/login.conf (on a FreeBSD) system would be more practical than the global file. That change has since been undone. I think we do need to look more into it, and I'm not sure what is at the bottom. Yes, ~pgsql/login.conf (on a FreeBSD) system would be more practical than the global file. That change has since been undone.

I think we do need to look more into it, and I’m not sure what is at the bottom.

]]> By: Greg Smith http://dan.langille.org/2009/04/17/lang-prevents-postgresql-initdb/#comment-318 Greg Smith Fri, 17 Apr 2009 18:42:43 +0000 http://dan.langille.org/?p=236#comment-318 The relevant documentation section isn't really obvious, how the server uses LANG is covered in http://www.postgresql.org/docs/8.3/static/locale.html if you didn't find that one yet, and the appropriate background to make sense of that is at http://www.opengroup.org/onlinepubs/007908775/xbd/locale.html Other relevant environment variables here are include LC_ALL and LC_COLLATE; you should compare those between the server that worked and the one that didn't. Rather than fiddling with the login info to change LANG, an alternate workaround would be to use the appropriate shell convention to get rid of LANG, like "unset LANG", then run initdb. You could do that as part of a script that runs initdb if you think LANG might be set to something odd. There's nothing wrong with manually specifying the encoding and locale at initdb time, as long as you recognize you won't be honoring how the OS it setup that way. I think you're stuck with digging into this a bit more before you can make the right decision for what you should do. The relevant documentation section isn’t really obvious, how the server uses LANG is covered in http://www.postgresql.org/docs/8.3/static/locale.html if you didn’t find that one yet, and the appropriate background to make sense of that is at http://www.opengroup.org/onlinepubs/007908775/xbd/locale.html Other relevant environment variables here are include LC_ALL and LC_COLLATE; you should compare those between the server that worked and the one that didn’t.

Rather than fiddling with the login info to change LANG, an alternate workaround would be to use the appropriate shell convention to get rid of LANG, like “unset LANG”, then run initdb. You could do that as part of a script that runs initdb if you think LANG might be set to something odd.

There’s nothing wrong with manually specifying the encoding and locale at initdb time, as long as you recognize you won’t be honoring how the OS it setup that way. I think you’re stuck with digging into this a bit more before you can make the right decision for what you should do.

]]>