Re: What is the maximum encoding-conversion growth rate, anyway?
От | Tatsuo Ishii |
---|---|
Тема | Re: What is the maximum encoding-conversion growth rate, anyway? |
Дата | |
Msg-id | 20070529.225132.104031803.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: What is the maximum encoding-conversion growth rate, anyway? (Tatsuo Ishii <ishii@postgresql.org>) |
Ответы |
Re: What is the maximum encoding-conversion growth rate, anyway?
Re: What is the maximum encoding-conversion growth rate, anyway? |
Список | pgsql-hackers |
> > On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote: > > > Tatsuo Ishii <ishii@postgresql.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. -- Tatsuo Ishii SRA OSS, Inc. Japan
В списке pgsql-hackers по дате отправления: