Demo variable injection

Before executing any demo SQL, three variables are injected: `{{zone_name}}` (target zone), `{{data_path}}` (zone-relative path to provisioned data), `{{current_user}}` (the authenticated username).

Category: demo-runner

Syntax

{{zone_name}} | {{data_path}} | {{current_user}}

Description

## Overview `demo-test` injects exactly three variables into every SQL file before it is split into statements: `{{zone_name}}`, `{{data_path}}`, and `{{current_user}}`. The injection is a plain string replacement, not an SQL parameter binding, so the substituted value appears as literal text in the statement. ## Behavior - Substitution happens once per phase, before the phase's SQL is split on `;`. - The matcher is `{{<name>}}` (double braces). Unknown names are left untouched. - Values are written verbatim, with one exception: if the variable name contains `path`, `dir`, or `location` (case-sensitive substring match), every `\` in the value is rewritten to `/`. Of the three built-in variables only `{{data_path}}` hits this rule, but the rule applies to any variable that happens to be named along those lines. - `{{data_path}}` is the zone-relative form (from the provision API's `data_subdir`), not the absolute on-disk path. Combined with the engine's zone location resolution this lets the same SQL work across zones without rewriting paths. - `{{zone_name}}` is the ZONE argument you passed, not an entity_ref. - `{{current_user}}` is the username the CLI authenticated with. It matches the value printed under `=== Authentication ===` on stderr. ## Compatibility - The three variables are stable: they have been present since `demo-test` first shipped and are what the `demo-run` skill and regression tooling depend on. - There is no user-extension mechanism in `demo-test`; you cannot pass additional `-D key=value` pairs the way `run` accepts them. To parameterise a demo further, put the values in the demo's SQL or in the control plane's demo manifest.

Parameters

Name	Type	Description
`{{zone_name}}`		The ZONE positional argument passed to `demo-test`. Substituted verbatim.
`{{data_path}}`		Zone-relative path to the provisioned demo data (the bare demo id, for example, `iceberg-uniform-basics`, since demos stage directly under `<zone>/<demo_id>/`). Taken from `data_subdir` on the provision response, with a fallback that strips the zone prefix from the absolute `data_path`. Because the variable name contains `path`, backslashes in the value are rewritten to forward slashes before substitution.
`{{current_user}}`		The authenticated CLI username (from the active profile). Handy for GRANT statements that target the runner.

Examples

-- In setup.sql
CREATE EXTERNAL TABLE orders
  USING CSV
  LOCATION '{{data_path}}/orders.csv';

-- In queries.sql
SELECT count(*) FROM {{zone_name}}.sales.orders;

-- In cleanup.sql
REVOKE ALL ON SCHEMA {{zone_name}}.sales FROM {{current_user}};

Pitfalls

Path normalisation rewrites `\` to `/` inside `{{data_path}}` before substitution. SQL that was authored assuming native Windows separators inside the substituted value will see forward slashes instead.
`{{data_path}}` is zone-relative, not absolute. Do not prefix it with the zone root again in SQL; the engine's location resolver joins it under the zone's storage root automatically.
Variable names are matched as literal substrings. A typo like `{{ data_path }}` (with spaces) is not recognised and will pass through to the engine as-is, producing a parse error.