Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. |
Дата | |
Msg-id | 201105251722.p4PHMaQ20183@momjian.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > Excerpts from Bruce Momjian's message of mar may 24 15:59:59 -0400 2011: > > > > I think you misread what I wrote, or I misexplained it, but never > > > mind. Matching locale names case-insensitively sounds reasonable to > > > me, unless someone has reason to believe it will blow up. > > > > OK, that's what I needed to hear. I have applied the attached patch, > > but only to 9.1 because of the risk of breakage. (This was only the > > first bug report of this, and we aren't 100% certain about the case > > issue.) > > Hmm, I know the locale can be spelled "en_US.UTF-8" (note dash) in some > systems. So if you have a locale alias that makes en_US.utf8 the same > as en_US.UTF-8, the patched code would still not work. I wonder if > there's a need for canonicalization somewhere. Or maybe this is just > not worth the trouble. I can easily remove dashes before the compare if people like that idea --- I think you could argue that a dash is not significant, unless "ab-c" and "a-bc" are different locales. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: