You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 62dacd9
Browse filesBrowse the repository at this point in the historyBrowse files
fix(sql): evaluate sequence-backed DEFAULT expressions on typed engines
`DEFAULT nextval('name')` passed DDL and then silently produced NULL on
every insert: the pure default evaluator does not recognize sequence
accessors, so the expression evaluated to "no value" and the column was
omitted — including primary keys (#294). The sequence machinery itself
exists on the control plane (SequenceRegistry with catalog persistence and
range allocation); this wires the SQL DEFAULT path to it.
- SequenceRegistry is threaded from SharedState through QueryContext into
ConvertContext (for_state / for_state_with_lease and both planning
sites); sub-planner contexts keep None.
- evaluate_sequence_default recognizes DEFAULT nextval('name'), advances
the CP-side registry, and raises a loud PlanError for unknown sequences —
a DDL-accepted DEFAULT never silently vanishes into NULL again.
- The INSERT/UPSERT expanded_rows loop prefers the sequence-aware evaluator
over the pure stateless one.
Verified: document_strict DEFAULT nextval fills distinct ids (1,2,3) across
inserts; unknown sequence raises naming the sequence; uuid defaults
unchanged. Out of scope here (tracked): SELECT nextval/currval evaluation,
kv/columnar-family defaults, schemaless document column defaults (dropped
at catalog adapter — pre-existing), currval/setval session semantics.
0 commit comments