Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patch

>.. 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