Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
От | Bruce Momjian |
---|---|
Тема | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |
Дата | |
Msg-id | 20120924143104.GD21242@momjian.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
|
Список | pgsql-hackers |
On Mon, Sep 24, 2012 at 10:13:45AM -0400, Tom Lane wrote: > 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. 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 especiallyuseful for figuring out* what locale name "" means (ie, the environment value). (Actually,* it seems that on mostimplementations that's the only thing it's good for;* we could wish that setlocale gave back a canonically spelled versionof* the locale name, but typically it doesn't.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: