Re: [BUGS] BUG #6034: pg_upgrade fails when it should not. - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.
Date
Msg-id 201105251722.p4PHMaQ20183@momjian.us
Whole thread Raw
In response to Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [BUGS] BUG #6034: pg_upgrade fails when it should not.  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Greg Smith
Date:
Subject: Re: tackling full page writes
Next
From: Vaibhav Kaushal
Date:
Subject: Re: Expression Evaluator used for creating the plan tree / stmt ?