Repository navigation
Compile a server's verbatim create_table_query for every engine: enforce CHECK, accept ASSUME and storage-only clauses #477
Description
Accept a server's verbatim create_table_query for every engine. Enforce what a server enforces, and accept what only affects storage.
The ask. Compiling the exact create_table_query a server returns (system.tables) should work for every engine a consumer meets:
MergeTreeand itsReplicated*variants,Distributed,Memory,Null,Log,Buffer, and the rest;- with
TTL(includingnow()),SETTINGS,PROJECTION,INDEXandCODECclauses.
The rules:
- Clauses that only shape storage (engine parameters,
TTL,PROJECTION,INDEX,CODEC, storageSETTINGS) are accepted and ignored for validation, not refused. (Corrected below: some tableSETTINGSdo change INSERT validation, so they are honoured, not ignored.) CONSTRAINT … CHECKis enforced exactly as a server enforces it. 1.0 already does this for the expression's type and value; seedocs/limitations.md.CONSTRAINT … ASSUMEmust be accepted.⚠️ A real server does not checkASSUMEon insert; it is an optimizer assumption, per ClickHouse's documentation (inferred; to be confirmed by the artifact producer's differential proof). So "enforce" here must mean matching the server, which means not rejecting rows on anASSUME.
Why. Today a downstream consumer reads system.columns and hand-builds a neutral CREATE TABLE … ENGINE = MergeTree ORDER BY tuple(). That drops the table's CHECK constraints, so the SDK cannot enforce them.
Related known gaps (docs/limitations.md):
- "A time-dependent TTL in a CREATE comes back as an internal error";
- "
SHOW CREATEof a Memory table is declined"; - MergeTree settings at a non-default value are declined by design. Revisit each under this issue.
Pairs with the per-schema server profile (#419) and discovery (to be filed).
Needs a library change from the artifact producer.
🤖 Generated with Claude Code
Activity
EricAndrechek commentedon Oct 6, 2026
Correction (
measuredby the artifact producer), and one confirmation.Correction. The body said storage-only clauses "cannot change whether a row is accepted". That is wrong. Some table
SETTINGSchange INSERT validation:CHECK;Nestedarray lengths (measured on 26.7.3.19).So "accept and ignore storage clauses" is not safe as a blanket rule. The rule becomes:
TTL,PROJECTION/INDEXdefinitions,CODEC) are accepted;SETTINGSare honoured where they change validation, exactly as the server applies them, and accepted as no-ops only where they cannot.Which settings fall in which class comes from the library's own reading of the server's code, never a hand list in a binding.
Confirmed:
CONSTRAINT … ASSUMEis accepted and not enforced. OnlyCHECKis checked, at all four supported tags. That matches a real server, so 1.0's behaviour here is the target.Being probed by the artifact producer: whether an
INDEXorPROJECTIONexpression that throws at INSERT on a real server is currently dropped by the compile. If confirmed, that is an over-accept, and it will be registered indocs/limitations.md.