I think I was thinking of how it is passed around internally,
the C representation, rather than how it is stored on the disk.
These are different things.
So, one byte user defined data types are possible. And that
means that the *storage* will be one byte (modulo alignment).
elein
On Sat, Oct 11, 2003 at 03:42:57AM +0200, Manfred Koizar wrote:
> On Fri, 10 Oct 2003 16:53:55 -0700, elein <elein@varlena.com> wrote:
> >I don't think that you can create a genuine one byte datatype.
> >The resulting type would probably be four bytes long, even if
> >you create a one byte by-value data type.
>
> Column values are not *expanded* to multiples of four bytes, they are
> *aligned* according to their datatype (cf. pg_type.typalign).
>
> Not counting heap tuple headers, we get the following offsets and
> lengths:
>
> CREATE TABLE a (
> c1 "char" NOT NULL, -- offset 0
> c2 "char" NOT NULL, -- offset 1
> c3 "char" NOT NULL, -- offset 2
> c4 "char" NOT NULL -- offset 3
> ); -- size = 4
>
> CREATE TABLE b (
> c1 bool NOT NULL, -- offset 0
> c2 int2 NOT NULL, -- offset 2
> c3 bool NOT NULL, -- offset 4
> c4 int NOT NULL, -- offset 8
> c5 bool NOT NULL, -- offset 12
> c6 char(1) NOT NULL -- offset 16
> ); -- size = 24
>
> Here c6 consists of a four byte length followed by one data byte
> (unless the character needs a multibyte representation), the length
> has to be aligned on a four byte boundary and the whole row is padded
> to a multiple of MAXALIGN, typically four on a 32 bit machine. So we
> have three padding bytes before c6 and three padding bytes after c6.
>
> CREATE TABLE bb (
> c6 char(1) NOT NULL, -- offset 0
> c1 bool NOT NULL, -- offset 5
> c3 bool NOT NULL, -- offset 6
> c5 bool NOT NULL, -- offset 7
> c4 int NOT NULL, -- offset 8
> c2 int2 NOT NULL -- offset 12
> ); -- size = 16
>
> Servus
> Manfred
