Added to TODO:
* Change memory allocation for multi-byte functions so memory is
allocated inside conversion functions
Currently we preallocate memory based on worst-case usage.
---
Tom Lane wrote:
> Tatsuo Ishii <[EMA
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tatsuo Ishii wrote:
> The conclusion of the discussion appears that we could reduce
> MAX_CONVERSION_GROWTH from 4 to
The conclusion of the discussion appears that we could reduce
MAX_CONVERSION_GROWTH from 4 to 3 safely with all existing built-in
conversions.
However, since user defined conversions could set arbitrary growth
rate, probably it would be better leave it as it is now.
For 8.4, maybe we could change
Sorry for dealy.
> On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote:
>
> > 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.
>
> Would it make sense to define just the
Where are we on this?
---
Tom Lane wrote:
> I just rearranged the code in mbutils.c a little bit to make it more
> robust if conversion of an over-length string is attempted, and noted
> this comment:
>
> /*
> * When conve
On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote:
> 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.
Would it make sense to define just the longest and shortest character
On Tue, May 29, 2007 at 10:00:06AM -0400, Tom Lane wrote:
> In practice though, I find it hard to imagine a pair of encodings for
> which the growth rate is more than 3x. You'd need something that
> translates a single-byte character into 4 or more bytes (pretty
> unlikely, especially considering
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> 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.
Seems to me that would be an argument for moving the palloc inside the
convers
> > On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> > > Tatsuo Ishii <[EMAIL PROTECTED]> 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 0x
> On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> 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).
On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> 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
> > u
> > Can we add a column to pg_conversion which represents the "growth
> > rate"? This would reduce the rate for most encodings much smaller than
> > 6.
>
> We need to do something, but the pg_conversion catalog seems a bad place
> to put the info --- don't we have places that need to be able to do
Tatsuo Ishii <[EMAIL PROTECTED]> 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.
> I just rearranged the code in mbutils.c a little bit to make it more
> robust if conversion of an over-length string is attempted, and noted
> this comment:
>
> /*
> * When converting strings between different encodings, we assume that space
> * for converted result is 4-to-1 growth in the wor
14 matches
Mail list logo
