> >> Hmm ... now that's an interesting thought. So the input converter would > >> actively strip trailing blanks, output would add them back, > > > But how would the output know how many to put back? > > The output routine would need access to the column typmod. Which it > would have, in simple "SELECT columnname" cases, but this is a serious > weakness of the scheme in general.
I think it is not really a weakness of the scheme, but a weakness that typmod is not available in some places where it would actually be needed. One effect of this is, that all the varlena datatypes have a redundant length info per row, even for such types that have the same length for all rows of one table (e.g. numeric(8,2), and char(n)). In a lot of cases that means 50-100% more disk space than actually needed. I can see, that making typmod availabe in more places would probably be major work (or not feasible at all), but I think it would generally be of (great) value. To the problem of concatenation: Would it be feasible to alter the concatenation method to concatenate the results of the output functions of the relevant expressions ? Imho that would actually return the expected results more often than it currently does, and it would fix the typmod issue for char(n) concatenation. Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
