Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id A382E1337B5C
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Wed, 16 Feb 2011 07:54:56 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 05337-07 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Wed, 16 Feb 2011 11:54:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22])
	by mail.postgresql.org (Postfix) with SMTP id B2B401337B4F
	for <pgsql-admin@postgresql.org>; Wed, 16 Feb 2011 07:54:48 -0400 (AST)
Received: (qmail invoked by alias); 16 Feb 2011 11:54:47 -0000
Received: from fsgw.f-secure.com (EHLO [10.128.133.18]) [193.110.108.33]
	by mail.gmx.net (mp006) with SMTP; 16 Feb 2011 12:54:47 +0100
X-Authenticated: #495269
X-Provags-ID: V01U2FsdGVkX1+jsEUX0oejiPbuuuomdY68j2Vm8osRri9PsnUGct
	OEcf62o2g1t+Dx
Subject: Re: LC_COLLATE and pg_upgrade
From: Peter Eisentraut <peter_e@gmx.net>
To: Bernhard Schrader <bernhard.schrader@innogames.de>
Cc: pgsql-admin@postgresql.org
In-Reply-To: <1297689493.2293.5.camel@schrader-laptop>
References: <1297357018.2340.10.camel@schrader-laptop>
	<1297689493.2293.5.camel@schrader-laptop>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 16 Feb 2011 13:54:45 +0200
Message-ID: <1297857285.8578.1.camel@fsopti579.F-Secure.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201102/145
X-Sequence-Number: 36784

On mån, 2011-02-14 at 14:18 +0100, Bernhard Schrader wrote:
> As far as I read right now, LC_COLLATE is a read_only variable which
> is used while initdb. But why does the pg_upgrade script doesn't see
> that utf8 and UTF-8 are the same? Is it just a string compare? 

Why don't you just reinitialize your new database cluster with the same
locale spelling as the old one?

Your points are valid, but unfortunately difficult to handle in the
general case.