Critical: no array / list column type in declarative schema (need text[]) — forces jsonb workarounds

[MelbourneDeveloper]

Summary

The declarative migration schema (migrations/schema.yaml, applied via DataProviderMigrate) has no array / list column type. There is no way to declare a Postgres text[] (or any T[]) column. This forces a jsonb workaround for every naturally-array-shaped column, which loses array typing, element constraints, and the ability to use Postgres array operators / GIN indexing.

Severity: critical for any schema that needs first-class array columns — it changes the data model (jsonb instead of text[]) and pushes validation that the DB could enforce up into application code.

Where this bit us (real case)

NAP's BYO-IdP end-user auth needs a per-tenant allow-list of permitted JWT signing algorithms — naturally a text[]. There is no array type, so we modelled it as Json (jsonb):

# migrations/schema.yaml
- name: allowed_algs
  type: Json                 # WANTED: a text[] / array type
  isNullable: false
  defaultValue: "'[]'::jsonb"

We could only make this safe because no RLS predicate parses the column — the verifier reads it in Python. If we had needed a DB-side constraint or an array containment check in a policy ('RS256' = ANY(allowed_algs)), jsonb would not have been sufficient and we'd have been stuck.

Types currently available

From a real production schema, the declarative types in use are: BigInt, Boolean, Date, DateTimeOffset, Decimal, Int, Json, Text, Uuid. None expresses an array.

Requested fix

Add a declarative array column type so text[] (and ideally uuid[], int[], etc.) can be expressed without dropping to jsonb. Strawman shape:

- name: allowed_algs
  type: Array
  elementType: Text
  isNullable: false
  defaultValue: "'{}'"

or an inline form such as type: "Text[]". Either is fine — the requirement is simply: a first-class array column type in the declarative schema, migrated the same one-pass way as every other column (no raw SQL / no separate post-migration step, since the consumer's hard rule is "no SQL/DDL in schema.yaml").

Why not just keep using jsonb

• jsonb arrays can't be used with native array operators (= ANY(...), @> on typed arrays) the way text[] can, including inside RLS policies.
• jsonb loses element typing — ["RS256", 7, null] is a valid jsonb array; text[] rejects it.
• It's a silent modelling compromise on every array-shaped column, not a one-off.

Context

Related docs gap: #72 (the documented column-type list is already known to be incomplete). This issue is about the missing capability, not just the docs.