tests: cover every SQL column type's ddl2cpp mapping on all three DBMS

[Yaraslaut]

Closes #191

What & why

The ddl2cpp column-type mapping was covered two ways, both partial:

• src/tests/CxxModelPrinterTests.cpp feeds CxxModelPrinter::MakeType a hand-written SqlSchema::Column, so it cannot notice a column type that fails to survive the DDL or the catalog round trip.
• The one end-to-end check in CI (ddl2cpp job) runs ddl2cpp over the Chinook schema, which exercises only the handful of column types Chinook happens to use.

Issue #191 proposed a DDL script for the missing types, and then noted the problem with it: a hand-written script is pinned to one dialect, so it could only ever run against SQLite.

This PR takes the route the issue suggests instead. src/tests/Ddl2CppColumnTypeTests.cpp never speaks SQL: every probe table is created through the dialect-agnostic migration query builder, read back out of the live catalog via SqlSchema::ReadAllTables, and only then handed to CxxModelPrinter::MakeType — the very function ddl2cpp emits record members with. The whole file runs unchanged against SQLite, MS SQL Server and PostgreSQL.

Note on the issue's other question ("would it make sense to move the actual logic of ddl2cpp into the core library?"): that has already happened — CxxModelPrinter lives in src/Lightweight/Tools/, and src/tools/ddl2cpp.cpp is only a CLI front end. So no library restructuring was needed here.

Coverage added

Column types: tinyint, smallint, integer, bigint, decimal(10,2), real, double, boolean, date, time, datetime, timestamp, char(8), varchar(30), text, binary(16), varbinary(16), nchar(8), nvarchar(30), guid.

Column properties: nullable vs. not-null (std::optional wrapping), auto-increment primary key, GUID primary key, VARCHAR primary key.

7 test cases / 88 assertions per database.

Per-DBMS divergences are recorded, not hidden

Where a backend stores something other than what was asked for, the deviation is a DialectException carrying its reason, so the divergences are written down in one place and continuously verified. The reason string is printed as Catch2 INFO when an assertion fails, so a future breakage explains itself.

Legitimate divergences captured: PostgreSQL has no 1-byte integer (Tinyint → int16_t); the PostgreSQL Unicode driver reports every character column as its wide ODBC type; SQLite has a single dynamically typed TEXT class, so CHAR(n) padding and the Unicode distinction are both lost; BYTEA carries no declared length; the SQL Server formatter emits VARBINARY(n) for Binary{n}; the schema reader deliberately widens float/real to Real{53}.

⚠️ Two genuine defects this coverage surfaced

Both are asserted as-is and labelled KNOWN DEFECT in the test, so the behaviour is recorded rather than going unnoticed. I did not fix either — each is a separate change with its own risk, and the second involves choosing a replacement type. Happy to split off follow-up issues/PRs if you want them handled.

1. PostgreSQL double precision generates float. The schema reader's float fixup (src/Lightweight/SqlSchema.cpp:1439) matches only the dialect type names float/real. PostgreSQL names its types float4/float8, so float8 misses the fixup and the driver-reported width narrows the column to 4 bytes. PostgreSqlFormatter::ColumnType already carries a comment about exactly this hazard on the write side ("or restore silently narrows it to float32"); the read side still has it. Generated records therefore lose precision on every double precision column.

2. MS SQL Server Timestamp{} generates Light::SqlDynamicBinary<8>. SqlServerFormatter::ColumnType emits TIMESTAMP verbatim, but on SQL Server TIMESTAMP is a deprecated synonym for rowversion — an 8-byte, server-generated, non-writable binary counter, not a point in time. So a migration asking for a timestamp gets a read-only binary column, and ddl2cpp then generates a binary member for it. DATETIME2 is the natural replacement.

Testing

	Databases	Result
clang-debug (PEDANTIC + ASan + UBSan)	sqlite3, mssql2022 (Docker, 16.00.4265), postgres (Docker 16.4)	full suite green — 1409 cases / ~13.7k assertions each
clang-tidy	—	clean on the new file (no NOLINT used); two findings fixed at the source (cppcoreguidelines-pro-type-member-init, readability-qualified-auto)
clang-format	—	applied

Compilers: Clang only, locally. The gcc-release preset is Linux-gated and CMake refuses it on this macOS host (Cannot use disabled configure preset), so per AGENT.md I am flagging that explicitly rather than claiming coverage I do not have — CI's ubuntu_build_cc_matrix / dbms_test_matrix legs are the GCC check for this branch. The change is a single self-contained test translation unit with no namespace-scope entities in public headers, so the modules and reflection configurations are unaffected.

• Performance impact: none on library code. Adds one test TU and ~5 short-lived probe tables per database run.
• Risk: low. Test-only; no production source touched. The one externally tunable expectation (PostgreSQL TEXT, whose reported length is the driver's MaxLongVarcharSize rather than a property of the column) is asserted by shape via StartsWith, not by exact number, so it will not break on a different psqlODBC build.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!