Integer DDL types collapse wire OID fidelity — INT/INTEGER/INT4/BIGINT all report OID 20; SMALLINT/INT2 report OID 25 (text) #217

Version / build tested against

farhansyah/nodedb:0.4.0 (published Docker image; SELECT version() → NodeDB 0.4.0, wire format 1). Not re-tested against current origin/main — close if already addressed.

Deployment mode

Origin — single node (local), observed at the wire level through a pgwire client (Crystal / nodedb.cr, decoding RowDescription OIDs directly).

Engine(s) involved

pgwire / client type fidelity — engine-independent DDL type mapping.

Summary

Every integer DDL keyword except SMALLINT/INT2 reports wire type OID 20 (int8/bigint) in RowDescription, regardless of the declared width — INT, INTEGER, INT4, BIGINT, and INT8 all come back as OID 20. SMALLINT/INT2 are worse: they report OID 25 (text), not int2, and the payload arrives as plain decimal text. A pgwire client that decodes strictly by the reported OID therefore (a) reads every INT/INTEGER column as 8-byte where it declared 4-byte, and (b) gets a text value where it expects a 2-byte integer for SMALLINT. The declared type and the wire-reported type disagree.

Steps to reproduce

DROP COLLECTION IF EXISTS fixprobe_ints;
CREATE COLLECTION fixprobe_ints (id TEXT PRIMARY KEY, a INT, b INTEGER, c INT4, d BIGINT, e INT8, f SMALLINT, g INT2);
INSERT INTO fixprobe_ints (id, a, b, c, d, e, f, g) VALUES ('r1', 1, 2, 3, 4, 5, 6, 7);
SELECT id, a, b, c, d, e, f, g FROM fixprobe_ints;

Inspect the RowDescription type OIDs on the wire (psql \gdesc, or any client that exposes column OIDs):

Re-verified on a second throwaway collection (f SMALLINT, g INT2 only, values 100, 200) — same result: oid=25 for both, row values arrive as plain decimal text ("100", "200"), no quoting/JSON wrapping.

Expected behavior

RowDescription OIDs should reflect the declared width: INT/INTEGER/INT4 → OID 23 (int4), BIGINT/INT8 → OID 20 (int8), SMALLINT/INT2 → OID 21 (int2). A Postgres-wire-compatible server's whole value proposition is that a stock pg client can decode by OID; today a client must special-case NodeDB (treat all INT as int8, and parse SMALLINT from text).

Actual behavior

All 4-byte and 8-byte integer keywords collapse to OID 20; SMALLINT/INT2 fall through to OID 25 text. Values are still correct once decoded with this knowledge, so it is a type-fidelity/compat defect, not data loss.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong
• 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-3 — Medium: breaks strict-by-OID pgwire clients (they read wrong widths or get text for SMALLINT), but values decode correctly once the client special-cases it. Workaround: decode all integer columns as int8, and SMALLINT/INT2 as text.

Reproducibility

Always — every attempt.

Environment & logs

Linux x86_64, farhansyah/nodedb:0.4.0 Docker image, single local node. Observed by decoding RowDescription OIDs directly through nodedb.cr's wire client. The nodedb.cr shard now documents "read NodeDB INT as Int64, SMALLINT/INT2 as text" as a known dialect quirk in its wire-facts.