Warm one plan per prepared case

[sergei-pustovykh]

Now a stored query with a signature gets one plan per PREPARE FOR case.

Each PREPARE FOR case is planned the way a client's prepared statement would be: warm-up binds the value a case pins, or passes only the type when the case pins none. A client whose bindings fit that case then finds a plan already built for it.

This is the last PR of the chain. Until now a signature and its PREPARE FOR cases were only syntax and storage; this is what makes them do something.
he cached-plan count not moving, which is the only way to catch a silent miss; PreparedCaseParamsTest covers the mapping without a database.

What a PREPARE FOR case becomes

PreparedCaseParams turns one case into the PreparedParams to plan it with. A state either binds a value or leaves the parameter without one:

state	warm-up passes	so the plan
IS_NULL	a real null	is folded at plan time — the predicate is gone, not evaluated
IS_TRUE	Boolean.TRUE	is folded for that value
IS_FALSE	Boolean.FALSE	is folded for that value
IS_NOT_NULL	no value, the declaration	is value-free, and a null binding cannot match it

Where to look

1. OfflineStoredQueriesProcessor.planStoredQuery — the per-case loop, and all five counter increments in one place.
2. planOneCase in the same class — why the temporary functions are compiled inside the loop rather than once.
3. PreparedCaseParams.of — the whole of what a case decides: which parameters get a value and which are left without one.
4. Tests: StoredQueriesTest proves a hit by t

What is not warmed

A parameter declared with a schema template type — a struct, an enum, or an array of either — is not warmed when a case leaves it value-free. The built schema template drops its named types (auxiliaryTypes live in the builder, are used by resolveTypes() and are gone after build()), so there is nothing to resolve the name against. The failure comes from the planning path, where the resolution happens, and is contained like any per-case planning failure: logged, counted, that case skipped. A lookup by name on the built template is already on the task list; when it lands these queries start warming, with no change here.

Primitives, UUID, VECTOR(128, FLOAT) and arrays of primitives all resolve — vectorType is part of primitiveType, so no lookup is needed for any of them.

This is not a runtime limitation. A bound struct carries its own metadata, so the query plans and runs normally, only cold. Pinning the same parameter IS NULL is warmed too, since that case binds a real value and needs no type.

Tests

PreparedCaseParamsTest, 7 cases, no database — the mapping from case to parameters is a pure function. What each state binds; that IS NOT NULL leaves no value; that declarations are passed on for every parameter whatever its state; a case mixing all three kinds; and that a value-free state with no declaration behind it is rejected here, so the failure names the missing declaration rather than surfacing later as a missing value.

StoredQueriesTest gains four cases, all against FDB, and asserts the counters alongside the cached-plan count: two plans warmed and none failed for one query with two cases, and — where a declaration cannot be resolved — one warmed, one failed, one query processed and one failed. That last set is what catches a counter incremented per query where it should be per case, since a wrong increment would make the four numbers agree. That one stored query with two cases warms two plans. That both are reachable from a client — proved by the cached-plan count not moving, since a miss would plan afresh and insert, which matters because the failure mode here is a silent miss and asserting on returned rows would not catch it. That a boolean pinned to each value gets a plan per value and each binding finds its own. And that a parameter type warm-up cannot resolve skips only that stored query, leaving the next one warmed — the same containment the temp-function failures already had.

Documentation

STORED_QUERY.rst gains a What is not warmed section — the general shape of a warm-up failure, the filtered-index case, and the schema template type — and a note in Signature that a template type in a signature needs the TYPE keyword, unlike a column definition which takes the bare name. That difference between columnType and functionColumnType was not derivable from the docs, and it is the mistake I made myself while writing the tests.

Stack

1. Add a typed named parameter signature and PREPARE FOR to CREATE STORED QUERY — declares each parameter's name, type and nullability, enumerates the plans to warm for them, and persists both alongside the query text.
2. Plan a named parameter from its declared type without a value — lets a query be planned when a parameter has a type but no value, and the declared type alone says which bindings the plan serves.
3. {this PR} Warm one plan per prepared case — builds each plan at startup through the prepared-statement path, and reports how many plans the cache was filled with.