Skip site navigation (1) Skip section navigation (2)

Re: What is the maximum encoding-conversion growth rate, anyway?

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: mike(at)fuhr(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: What is the maximum encoding-conversion growth rate, anyway?
Date: 2007-05-29 13:51:32
Message-ID: 20070529.225132.104031803.t-ishii@sraoss.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> > 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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-05-29 14:00:06
Subject: Re: What is the maximum encoding-conversion growth rate, anyway?
Previous:From: Michael GlaesemannDate: 2007-05-29 13:35:51
Subject: Re: [HACKERS] Users specific to a Database

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group