From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: char(n) to varchar or text conversion should strip |
Date: | 2002-11-19 09:15:49 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961EFE@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Haworth | 2002-11-19 12:19:48 | Re: DBD::PostgreSQL |
Previous Message | Justin Clift | 2002-11-19 05:41:15 | Re: Press Release -- Just Waiting for Tom |