> > On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> > > Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> > > > I'm afraid we have to mke it larger, rather than smaller for 8.3. For
> > > > example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becomes *pair* of 3
> > > > bytes UTF_8 (0x00e3818b and 0x00e3829a). See
> > > > util/mb/Unicode/shift_jis_2004_to_utf8_combined.map for more details.
> > >
> > > > So the worst case is now 6, rather than 3.
> > >
> > > Yipes.
> > Isn't MAX_CONVERSION_GROWTH a multiplier? Doesn't 2 bytes becoming
> > 2 * 3 bytes represent a growth of 3, not 6? Or does that 2-byte
> > SHIFT_JIS_2004 sequence have a 1-byte sequence in another supported
> > encoding? Or am I missing something?
> Oops. You are right. The MAX_CONVERSION_GROWTH should be 3 (=
> (2*3)/2), rather than 6 for the case.
> So it seems we could safely make MAX_CONVERSION_GROWTH down to 3 for
> the moment.
Thinking more, it striked me that users can define arbitarily growing
rate by using CFREATE CONVERSION. So it seems we need functionality to
define the growing rate anyway.
SRA OSS, Inc. Japan
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-05-29 14:00:06|
|Subject: Re: What is the maximum encoding-conversion growth rate, anyway? |
|Previous:||From: Michael Glaesemann||Date: 2007-05-29 13:35:51|
|Subject: Re: [HACKERS] Users specific to a Database|