From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'hackers(at)postgresql(dot)org'" <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patch |
Date: | 1998-05-22 10:10:49 |
Message-ID: | 01BD857A.C41189F0@zeugswettera.user.lan.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>.. 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jose' Soares Da Silva | 1998-05-22 10:52:19 | error messages not only English |
Previous Message | Peter Mount | 1998-05-22 10:07:23 | RE: [HACKERS] error messages not only English |