Named Types, Enums and Domains
KalamDB named types let tables and routines share one data contract. Use an enum for a fixed set of labels, a composite for structured values, and a domain for a constrained scalar.
Create KalamDB types
Enums are case-sensitive. Composites can contain other named types and arrays; named dependencies must exist first. A table also creates its implicit row type with the same name. Domains apply their default, nullability and check constraints where the domain is used.
Enum types
Enum member identity is preserved when a label is renamed, including existing stored values. Do not treat enum labels as arbitrary strings in generated application code.
Composite types
Composite types support empty and nested structures. Tables that reference a type keep a dependency on it. Dropping a referenced type or table row type without resolving its dependents fails.
Domains
Use domains for shared scalar validation. Table-level CHECK declarations are not an equivalent enforcement guarantee in the tested 0.8 server; see the table constraint limits. Domain checks use VALUE for the candidate value.
Use with tables and procedures
Functions declare RETURNS; procedures use OUT or INOUT. PostgreSQL routine signatures discard parenthesized type modifiers such as NUMERIC(12, 2) for overload identity. Table columns and composite fields retain their declared modifiers.
ALTER TYPE
ALTER TYPE supports composite attribute evolution and enum value operations. For a table column conversion, use ALTER TABLE ... ALTER COLUMN ... TYPE ... USING ...; existing rows are converted and a failed conversion must not leave a partially converted table.
DROP TYPE
Remove dependent objects first, or use supported cascade behavior only when the dependent objects should also be removed. Range, multirange and shell CREATE TYPE forms are not supported in 0.8.
Next: Scalar data types. Reference: Server routines.