Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TG9gi-0001PU-38 for pgsql-hackers@postgresql.org; Mon, 24 Sep 2012 14:31:08 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TG9gg-0004D5-TJ for pgsql-hackers@postgresql.org; Mon, 24 Sep 2012 14:31:07 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1TG9ge-00062P-Ub; Mon, 24 Sep 2012 10:31:04 -0400 Date: Mon, 24 Sep 2012 10:31:04 -0400 From: Bruce Momjian To: Tom Lane Cc: Peter Eisentraut , Rural Hunter , PostgreSQL-development Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed Message-ID: <20120924143104.GD21242@momjian.us> References: <20120917210723.GA30394@momjian.us> <20120918232239.GA2014@momjian.us> <505C307E.20501@gmail.com> <1348403628.18490.1.camel@vanquo.pezone.net> <505F1A98.9090901@gmail.com> <1348440393.18490.2.camel@vanquo.pezone.net> <20120924125500.GA21242@momjian.us> <50605ABC.1000304@gmx.net> <20120924130820.GB21242@momjian.us> <14327.1348496025@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14327.1348496025@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.7 (--) X-Archive-Number: 201209/880 X-Sequence-Number: 213908 On Mon, Sep 24, 2012 at 10:13:45AM -0400, Tom Lane wrote: > Bruce Momjian writes: > >>> I can confirm that pg_upgrade does case-insensitive comparisons of > >>> encoding/locale names: > > > Or we could just remove dashes from the name before comparisons. > > That would merely move the breakage somewhere else. I think you are > already assuming far too much about the OS' interpretation of locale > names by assuming they are case-insensitive. Assuming that dashes > aren't significant seems 100% wrong. > > FWIW, what I found out last time I touched this code is that on many > systems setlocale doesn't bother to return a canonicalized spelling; > it just gives back the string you gave it. It might be worth doing > what Peter suggests, just to be consistent with what we are doing > elsewhere, but I'm not sure how much it will help. This comment in initdb.c doesn't sound hopeful: * If successful, and canonname isn't NULL, a malloc'd copy of the locale's * canonical name is stored there. This is especially useful for figuring out * what locale name "" means (ie, the environment value). (Actually, * it seems that on most implementations that's the only thing it's good for; * we could wish that setlocale gave back a canonically spelled version of * the locale name, but typically it doesn't.) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +