Strict-schema engines (document_strict, kv) reject standard integer type spellings INT4 / INT8 / SMALLINT / INT2 at DDL time #223

Version / build tested against

origin/main @ f7fcc7718 (release build, fresh data dir; reproduced live today).

Deployment mode

Origin — single node (local), via psql over pgwire.

Engine(s) involved

document_strict and kv — the ColumnType-backed strict-schema engines. (Schemaless/columnar/timeseries engines accept these spellings — see #217 for their separate wire-fidelity defect.)

Summary

The strict-schema engines reject the standard Postgres integer type spellings INT4, INT8, SMALLINT, and INT2 at DDL time with unknown column type, while accepting INT, INTEGER, and BIGINT. The same spellings are accepted by the schemaless engine family, so the DDL surface is inconsistent across engines, and Postgres-compatible tooling that emits int4/int2 spellings fails on strict engines only. Root cause: ColumnType::from_str (nodedb-types/src/columnar/column_parse.rs:124) matches only "BIGINT" | "INT64" | "INTEGER" | "INT".

Steps to reproduce

CREATE COLLECTION strict_probe (id TEXT PRIMARY KEY, a INT4) WITH (engine='document_strict');
-- ERROR:  parse error: unknown column type: 'INT4'

CREATE COLLECTION strict_probe2 (id TEXT PRIMARY KEY, f SMALLINT) WITH (engine='kv');
-- ERROR:  parse error: column 'f': unknown column type: 'SMALLINT'

Expected behavior

INT4/INT8/SMALLINT/INT2 accepted as aliases of the existing integer type (as the schemaless engines already do), so DDL is consistent across engines and standard Postgres type spellings work everywhere.

Actual behavior

DDL fails with parse error: unknown column type on strict engines only.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong
• The process crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (spell the types INT / INTEGER / BIGINT)

Proposed severity

SEV-3 — Medium: DDL-surface inconsistency and Postgres-compat gap; clean workaround exists.

Reproducibility

Always — every attempt.

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

Not a regression — the accepted-spellings list has been this narrow since the match arm was introduced.

Environment & logs

Linux x86_64, source build of origin/main @ f7fcc7718, single local node, fresh data dir. Found while tracing #217 (integer OID wire fidelity on the schemaless path). Note for triage: accepting the aliases is a one-arm change and is planned as part of the #217 fix PR; however, wire-OID width fidelity for strict engines is a separate, larger piece — ColumnDef carries no declared-width field (ColumnType has a single Int64 variant), so even with aliases accepted, strict-engine columns will report OID 20 for all integer widths until ColumnDef grows a declared-type hint. That deeper half is deliberately out of the #217 PR's scope.

Before submitting

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