From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [v9.2] make_greater_string() does not return a string in some cases |
Date: | 2011-09-22 16:35:56 |
Message-ID: | 23159.1316709356@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Sep 22, 2011 at 11:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, the metric that we were indirectly using earlier was the
>> number of characters in a given locale for which the algorithm
>> fails to find a greater one (excluding whichever character is "last",
>> I guess, or you could just recognize there's always at least one).
> What about characters that sort differently in sequence than individually?
Yeah, there's a whole 'nother set of issues there, but the character
incrementer is unlikely to affect that very much either way, I think.
> But now that I think about it, what about using some
> slightly-less-stupid version of that approach as a fallback strategy?
> For example, we could pick, oh, say, 20 characters out of the space of
> code points, about evenly distributed under whatever collations we
> think are likely to be in use.
Sure, if the "increment the top byte" strategy proves to not accomplish
that effectively. But I'd prefer not to design a complex strategy until
it's been proven that a simpler one doesn't work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2011-09-22 22:43:45 | drop enum problem |
Previous Message | Robert Haas | 2011-09-22 16:09:45 | Re: [v9.2] make_greater_string() does not return a string in some cases |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2011-09-22 16:38:01 | Re: Unlogged vs. In-Memory |
Previous Message | Robert Haas | 2011-09-22 16:09:45 | Re: [v9.2] make_greater_string() does not return a string in some cases |