...

The start of the first element is implied and is always equal to zero.

Value area

...

Contains data for each tuple field one after another as described above.

Field Values

The list of supported data types for tuple fields is the same as in IEP-54[1]. Fixed-size values are stored in the little-endian byte order. If a value is equal to NULL then it is absent in the value area. This means that in the offset table the corresponding entry is equal to the previous entry. At the same time the corresponding bit in the nullmap is set.

Hence for any variable-length field as we find its length from the offset table we can encounter the case when the length is equal to zero. At this point the value has to be disambiguated in this way:

1. If the corresponding nullmap bit is clear then this is a zero-length (empty) value;
2. If the corresponding nullmap bit is set then this is a NULL value.

This approach is naturally extended to fixed-size fields. But instead of zero-length value we interpret it as a value of zero. That is 0 for integer fields, 0.0 for floating point fields, and whatever default value is for more complex types like date and time.

Integer Field Compression

This is optional  and  subject to discussion.

Uniform use of offset tables for all fields lets us take advantage of variable-length principle for integer fields.

Thus for integer values it is possible to keep only their significant bytes, omitting their high insignificant bytes. That is even if the original data type of a field is INTEGER and should occupy 4 bytes but the actual value is below 128 and above -129 then we can store it just as a single byte and reflect this in the offset table.

Reference Links

1. IEP-54: Schema-first Approach

...