Re: char(n) to varchar or text conversion should strip
От | Tom Lane |
---|---|
Тема | Re: char(n) to varchar or text conversion should strip |
Дата | |
Msg-id | 20106.1037713377@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: char(n) to varchar or text conversion should strip ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Список | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: > 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)). That argument doesn't hold any water, seeing that neither of your examples are actually fixed-width... numeric doesn't store leading or trailing zeroes, and char(n) is not a fixed-width item when dealing with multibyte encodings. And on top of that, there's TOAST to think about. So I don't think there's any shot at getting rid of the varlen word. > 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. No, it wouldn't really fix the typmod issue; you still have the problem of where is the output function going to get the typmod from? If the concatenation argument is anything but a simple column reference, you've still got trouble. regards, tom lane
В списке pgsql-hackers по дате отправления: