isthmus: derive the Calcite type system's limits from a Substrait dialect instead of hardcoding them

[nielspardon]

Thesis

Isthmus should be initializable from a Substrait dialect, and that dialect's declared type limits should drive the Calcite type system it builds — rather than the limits being hardcoded in SubstraitTypeSystem as they are today.

The dialect model already carries exactly the information needed: SupportedType exposes maxPrecision(), maxScale() and maxLength() as Optional<Integer> (added in #808). Nothing consumes them — grep -rl 'io.substrait.dialect' isthmus/src/main/java returns no files, and SubstraitTypeSystem is a hardcoded switch: 6 for the TIME/TIMESTAMP/TIMESTAMP_WITH_LOCAL_TIME_ZONE/INTERVAL_* family, 38 for DECIMAL, with getMaxScale overriding only DECIMAL.

The result is that "what precision can this target actually represent" is currently a property of Isthmus rather than of the engine being targeted, even though we publish per-engine dialects that are entitled to say so.

Why this is worth doing

Every hardcoded limit is a place where Isthmus either rejects a plan the target could execute, or accepts one it cannot. Three existing issues are all instances of the same missing seam:

• isthmus: Substrait→Calcite conversion rejects precision_time / precision_timestamp / precision_timestamp_tz precision > 6 #995 — Substrait→Calcite rejects precision_time/precision_timestamp/precision_timestamp_tz above 6, though the spec allows 0–12. That issue asks whether the hardcoded ceiling can be raised; dialect-driven limits reframe it as "whose ceiling is it", which is the more answerable question.
• isthmus: precision_timestamp_tz literals cap at precision 3 converting to Calcite and come back as plain precision_timestamp #1113 — the precision_timestamp_tz literal guard reads SqlTypeName.TIMESTAMP_TZ, which SubstraitTypeSystem does not override, so it caps at Calcite's default 3 while the type conversion caps at 6. A single declared source of limits removes the class of bug where two lookups disagree.
• Spark hardcodes the same number independently: Util.assertMicroseconds throws for any interval_day precision but 6, and ToSubstraitType only ever emits 6. Spark reaches Substrait without going through Isthmus, so it would need to consume the dialect on its own, but the hardcode is the same shape.

Known blocker: the type system is a reflectively-constructed singleton

SubstraitTypeSystem exposes TYPE_SYSTEM and TYPE_FACTORY as static singletons and keeps an explicit public no-arg constructor because Frameworks/Avatica reinstantiates the class from its class name via reflection. A dialect-parameterized type system cannot be constructed that way, so the instance has to be threaded explicitly rather than discovered by name.

The seam for that already exists: ConverterProvider.Builder.typeFactory(RelDataTypeFactory) lets a caller supply the factory, and TypeConverter.toCalcite takes the RelDataTypeFactory as a parameter throughout. What is missing is that nothing constructs a dialect-derived one, and the no-arg reflective path needs to keep working as a permissive default.

Correctness prerequisite

For intervals, Calcite splits the two dimensions: IntervalSqlType.getPrecision() is the leading-field bound (getMaxPrecision) and getScale() is the fractional-second bound (getMaxScale). SubstraitTypeSystem overrides getMaxPrecision(INTERVAL_DAY) to 6 and does not override getMaxScale for any interval, so the fractional-second ceiling is still Calcite's 9 while the digit count callers actually consult is the leading-field one. Any dialect that declares maxScale on interval_day would therefore be ignored today.

Whichever direction this goes, the interval limits need to be read through getMaxScale (of INTERVAL_DAY_SECOND, which is the SqlTypeName the produced type carries) before a dialect can meaningfully set them.

Relationship to #1013

Sibling axis, not a child. #1013 is entirely about operations — function mapping, relation mapping, the dialect-boundary unparse layer, and faithful-vs-compatible mode selection. Type limits share its "dialect at the boundary" principle but none of its four work items, and this is independently landable without the function-mapping foundation in #1012.

Open questions

• Behaviour on exceeding a limit. Reject (today's behaviour for datetime precision), narrow silently, or make it a configurable policy? Rejecting is honest but makes some plans unconvertible; narrowing is lossy in ways isthmus: precision_timestamp_tz literals cap at precision 3 converting to Calcite and come back as plain precision_timestamp #1113 shows are easy to miss.
• Dialect limits vs. Calcite's own capabilities. A dialect could declare a limit Calcite cannot represent. Does the effective limit become the intersection, and does exceeding Calcite's side produce a distinguishable error?
• Default with no dialect supplied. Today's hardcoded values as a permissive baseline, or the union of the shipped dialects?
• Which limits are in scope. maxPrecision/maxScale/maxLength are what SupportedType carries; getMaxNumericPrecision/getMaxNumericScale and the string-length caps are the other knobs RelDataTypeSystem exposes.

🤖 Generated with AI

[alexandrefimov]

The correctness-prerequisite section has a sharper consequence than a dialect's maxScale being ignored: the leading-field cap is below what the spec needs, and which cap you get depends on how the type is spelled. Through the validator on origin/main:

SELECT INTERVAL '3650000' DAY(7)                    -> Interval leading field precision '7' out of range for INTERVAL DAY(7)
SELECT CAST(NULL AS INTERVAL DAY(7))                -> same
SELECT CAST(NULL AS INTERVAL DAY(10) TO SECOND(9))  -> OK, precision=10 scale=9
SELECT CAST(NULL AS INTERVAL DAY(11) TO SECOND(9))  -> out of range

The getMaxPrecision switch lists INTERVAL_DAY, INTERVAL_YEAR and INTERVAL_YEAR_MONTH, but not INTERVAL_DAY_SECOND — so the day-to-second spelling keeps Calcite's default of 10 while the bare-day spelling gets 6. interval_day covers ±3,650,000 days, which is 7 digits, so the 6 rejects a leading field the type is defined to reach; and INTERVAL_DAY_SECOND, which is the SqlTypeName Isthmus actually produces for interval_day<P>, is the one name the override does not cover.

The year side is safe by luck rather than by design: ±10,000 years is 5 digits, so 6 has room.

That looks like a correctness fix that does not have to wait for the dialect seam — either drop the interval entries and let Calcite's 10 stand, or extend the switch to INTERVAL_DAY_SECOND with a value the spec's range fits. Want it as its own issue, or does it read better as the first step here?

[nielspardon]

#1169 is another instance: it lifts getMaxPrecision for CHAR, VARCHAR and BINARY from RelDataTypeSystemImpl's default of 65536 to Integer.MAX_VALUE, derived from the proto's int32 length rather than from a dialect. max_length on type_fixed_char, type_varchar and type_fixed_binary covers exactly those three.

One thing the other instances don't show: the limit reaches literal values, not just type declarations. Isthmus pads a fixedchar literal out to its declared width (#1171), so a ceiling of Integer.MAX_VALUE yields an OutOfMemoryError rather than a merely wrong type.

[alexandrefimov]

Measured the value side on #1169: with the ceiling at Integer.MAX_VALUE, CAST(x'01' AS BINARY(2147483647)) and CAST('a' AS CHAR(2147483647)) end in OutOfMemoryError inside Calcite's constant reduction, before isthmus sees a literal at all — stacks in #1169 (comment). Varchar and column casts come through fine, so it is the two padded types and only for literals, which is exactly what max_length covers.

[nielspardon]

@alexandrefimov its own issue, and it can land now — filed as #1221. It is not gated on the dialect seam; if anything it is a prerequisite, since a dialect declaring an interval limit today would be setting the dimension nothing reads.

Two corrections to this issue's Correctness prerequisite section, which is now partly stale. #1120 already landed the getMaxScale read it asks for: TypeConverter.visit(Type.IntervalDay) checks getMaxScale(SqlTypeName.INTERVAL_DAY_SECOND) and says why in a comment. And "any dialect that declares maxScale on interval_day would therefore be ignored today" is now the other way round — maxScale is the knob that works, and maxPrecision is the one that would land on the leading field, which no Substrait type carries.

What is left is narrower than the section implies, so #1221 restates it: the three interval entries are consulted by neither conversion direction, and their only live effect is on Calcite's own validator, where it is purely subtractive. Two things worth having here as well. Your measurements plus one more spelling: INTERVAL '3650000' DAY(6) fails with "Interval field value 3’650’000 exceeds precision of DAY(6) field", so the top of the day range is unreachable at every accepted spelling of the bare-day form, not just at DAY(7). And SqlIntervalQualifier.getStartPrecision defaults to getMaxPrecision(typeName()), so the override also decides what a bare DAY qualifier carries — 6 here, 10 under Calcite's default — which is a second, quieter divergence from the INTERVAL_DAY_SECOND path.

On this issue's own thesis, the interval case sharpens the Dialect limits vs. Calcite's own capabilities question better than the examples currently listed, because it is the first one where the two genuinely do not intersect: the spec allows interval_day<P> up to P=12, and Calcite's default getMaxScale for an interval is 9. That one is overridable rather than a wall — MAX_INTERVAL_FRACTIONAL_SECOND_PRECISION appears nowhere in Calcite outside RelDataTypeSystemImpl's own default, and validateIntervalQualifier reads the type system — but whether Calcite's interval arithmetic survives P > 9 is untested, so "does the effective limit become the intersection" has a concrete case to answer rather than a hypothetical one. #995 is the same shape on the datetime side and #1221 leaves the datetime caps alone deliberately, so the two stay separable.

Checked on main @ 85c03c7.