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 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match