Follow-up to PR #56 (template variables); surfaced by the PR #56 code review.
config validate accepts a known generator like {{uuid}} in database.templates.<t>.sql, but the db runtime path only substitutes generators in free-form --sql — template SQL binds via :paramName with no fill_placeholders site, so the token is sent literal to the DB. This is a validate-passes / runtime-literal inconsistency.
DESIGN §2.5 was scoped in PR #56 to document this (free-form --sql only). This issue tracks the actual fix: decide whether to add a generator fill site for template SQL (and the implication for :paramName interaction), or keep it documented-as-not-supported and have config validate reject {{...}} in template SQL to remove the surprise. Not a regression (pre-existing boundary); deferred because it needs a fill-site design decision.
Follow-up to PR #56 (template variables); surfaced by the PR #56 code review.
config validateaccepts a known generator like{{uuid}}indatabase.templates.<t>.sql, but the db runtime path only substitutes generators in free-form--sql— template SQL binds via:paramNamewith nofill_placeholderssite, so the token is sent literal to the DB. This is a validate-passes / runtime-literal inconsistency.DESIGN §2.5 was scoped in PR #56 to document this (free-form
--sqlonly). This issue tracks the actual fix: decide whether to add a generator fill site for template SQL (and the implication for:paramNameinteraction), or keep it documented-as-not-supported and haveconfig validatereject{{...}}in template SQL to remove the surprise. Not a regression (pre-existing boundary); deferred because it needs a fill-site design decision.