| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
| Cc: | mike(at)fuhr(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: What is the maximum encoding-conversion growth rate, anyway? |
| Date: | 2007-05-29 14:00:06 |
| Message-ID: | 3620.1180447206@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> 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
conversion functions, as I suggested before.
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 we require all these encodings to be
ASCII supersets); or something that translates a 2-byte character into
more than 6 bytes.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2007-05-29 14:04:12 | Re: TOAST usage setting |
| Previous Message | Tatsuo Ishii | 2007-05-29 13:51:32 | Re: What is the maximum encoding-conversion growth rate, anyway? |