Re: char(n) to varchar or text conversion should strip - Mailing list pgsql-hackers

From Tom Lane
Subject Re: char(n) to varchar or text conversion should strip
Date
Msg-id 20106.1037713377@sss.pgh.pa.us
Whole thread Raw
In response to Re: char(n) to varchar or text conversion should strip  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List 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 by date:

Previous
From: Adrian Calvin
Date:
Subject: Question regarding effects of Vacuum, Vacuum Analyze, and Reindex
Next
From: Patrick Welche
Date:
Subject: Re: RC1?