>.. and for ordinary column datatypes of fixed properties, it needn't
>have *any* fields. That would more than pay for the space cost of
>supporting a variable-width data type, I bet. I like this.
Actually not, since attypmod is stored with the table definition, it does not waste any space
on a per tuple basis. So I think the correct solution would rather be to extend the atttypmod idea
(maybe make atttypmod an array). Maybe we should add a atttypformat field of type varchar()
(this could be used for language and the like).
It would be rather bad to convert fixed length fields into varlena, since varlena costs a lot
during tuple access. The cheapest rows are those that have an overall fixed length.
So I think it is best to store as much info with the table definition as possible.
> Once atttypmod is exposed to applications it will be much harder to
> change its representation or meaning, so I'd suggest getting this right
> before 6.4 comes out. If that doesn't seem feasible, I think I'd even
> vote for backing out the change that makes atttypmod visible until it
> can be done right.
atttypmod is the right direction, it only currently lacks extendability.
Andreas