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 <[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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
