From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Peter Eisentraut <peter_e@gmx.net>, Rural Hunter <ruralhunter@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
In-reply-to: <20120924130820.GB21242@momjian.us>
References: <20120917043236.GA20123@momjian.us> <5056AF29.3040903@gmail.com>
	<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>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Mon, 24 Sep 2012 09:08:20 -0400"
Date: Mon, 24 Sep 2012 10:13:45 -0400
Message-ID: <14327.1348496025@sss.pgh.pa.us>

Bruce Momjian <bruce@momjian.us> 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.

			regards, tom lane