CREATE SEQUENCE succeeds but nextval/currval raise 42883; DEFAULT nextval(...) passes DDL then silently writes NULL

[emanzx]

Version / build tested against

origin/main @ 2886155

Deployment mode

Origin — single node (local)

Engine(s) involved

Not engine-specific / unsure

Summary

CREATE SEQUENCE succeeds, but the sequence cannot be used: nextval('name') (and currval/setval) raise 42883 "function nextval(...) does not exist" because the resolver's plan-time function-existence gate consults a registry that does not contain the sequence accessors. Worse, DEFAULT nextval('name') is accepted at DDL time on a column — including a PRIMARY KEY — and then silently evaluates to NULL on every insert, so the table fills with NULL keys and no error ever surfaces. The DDL path and the expression path disagree about whether nextval exists, and the runtime DEFAULT path still has the silent NULL fallback that the plan-time gate was built to prevent.

Steps to reproduce

CREATE SEQUENCE seqprobe;          -- CREATE SEQUENCE (accepted)

SELECT nextval('seqprobe');
-- ERROR:  function nextval(...) does not exist    <- the object just created is unreachable

SELECT currval('seqprobe');
-- ERROR:  function currval(...) does not exist

-- The DDL path happily accepts the same function the query path rejects:
CREATE COLLECTION seqt (id BIGINT DEFAULT nextval('seqprobe') PRIMARY KEY, v TEXT);
-- CREATE COLLECTION

INSERT INTO seqt (v) VALUES ('one');   -- INSERT 0 1
INSERT INTO seqt (v) VALUES ('two');   -- INSERT 0 1

SELECT id, v FROM seqt;
--  id |  v
-- ----+-----
--     | one
--     | two
-- (2 rows)        <- DEFAULT silently produced NULL into a PRIMARY KEY, twice

Expected behavior

Either the sequence accessors work end to end — nextval/currval/setval registered as callable functions, resolved against the sequence catalog, SELECT nextval('seqprobe') returns 1 then 2 — or CREATE SEQUENCE and DEFAULT nextval(...) are rejected up front as unsupported. In no case should a DDL-accepted DEFAULT expression evaluate to silent NULL at insert time; if the expression cannot be evaluated, the insert (or better, the DDL) should fail loudly.

Actual behavior

The sequence object is created and orphaned: every documented accessor raises 42883. The DDL path does not validate the DEFAULT expression against the same function registry, so a DEFAULT nextval(...) column passes DDL and then the runtime evaluator's unknown-function fallback yields NULL per row — compounding into NULL primary keys (the NULL-pk acceptance is filed separately; this issue is the sequence/DEFAULT path that produces the NULLs).

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong — NULLs committed where sequence values were declared; stored data otherwise intact
• The server crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (rewrite the query, avoid one path, etc.)

Proposed severity

SEV-2 — High: major functionality broken or silently-wrong results; stored data intact

Reproducibility

Always — every attempt

Last known-good version / commit (if a regression)

Unknown — nextval appears in the planner's known-functions list but not in the registry the existence gate consults, so the split has likely existed since the gate landed.

Environment & logs

Linux x86_64, release build from a fresh data directory, trust mode, pgwire via psql 16. No relevant server log lines.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on a released tag or a current main build (not a stale local branch).
• This is not a security vulnerability (those go to a private advisory).

[EnRaiha]

Partially addressed by #303: sequence-backed DEFAULT expressions (DEFAULT nextval('name')) now evaluate on typed engines — the CP-side registry advances per insert and unknown sequences raise loudly instead of silently NULLing the column (verified: strict engine fills ids 1,2,3).

Still open here: SELECT nextval/currval/setval (unchanged 42883), kv/columnar-family defaults, schemaless-document column defaults (dropped at catalog adapter — a pre-existing gap also affecting UUID defaults), and currval/setval session semantics. Tracked in the PR body's out-of-scope list.