Select persisted features

Persisted features can be evaluated by full name, selected as a filtered set, or temporarily overridden for one query without changing the registry.

Select a feature by name

Use the fully qualified name when you know the exact feature you want. Bind any INPUT() features required by its dependency graph:

RETURN
    FM.SALES.NET_REVENUE
FOR
    FM.SALES.ORDER_ID := BIND_VALUE(42);

You can use FROM FM.SALES to shorten repeated names, but a fully qualified name is clearer when a query touches several namespaces. See Namespaces and aliases .

Select a filtered set

*(FEATURES ...) expands to every persisted feature that matches the same filter language used by SHOW FEATURES. Use it when you intentionally want a namespace or dependency-based set rather than a fixed list:

RETURN
    fm.tutorials.explore.feature1,
    fm.tutorials.explore.feature11,
    fm.tutorials.explore.feature12,
    fm.tutorials.explore.feature2
;

Wildcard selection can be mixed with explicitly named features. Make the expansion deterministic with ORDER BY NAME when consumers rely on a stable column order:

RETURN
    FM.TUTORIALS.EXPLORE.FEATURE1,
    *(FEATURES IN FM.TUTORIALS.EXPLORE WHERE NAME like '%2')

Dependency predicates work here too. This query selects every feature downstream of a given input:

RETURN
    fm.tutorials.explore.rfeature2,
    fm.tutorials.explore.rfeature3,
    fm.tutorials.explore.rfeature4
FOR
    fm.tutorials.explore.rfeature0 := BIND_VALUE(2),
    fm.tutorials.explore.rfeature1 := BIND_VALUE(3)
;

Prefer explicit names for stable application contracts. Wildcards are most useful for exploration, debugging, and intentionally evolving exports. FORMAT and validate() do not support *(FEATURES ...) yet.

Test a local override

Assign a new definition to a fully qualified persisted name inside RETURN or DEFINE to override it for that query. Downstream persisted features recompute from the override, while the registry keeps its original definition.

This is useful for scenario analysis, debugging, and testing a proposed definition before publishing it with CREATE OR REPLACE.

Create a dependency chain

The next examples use FEATURE3 → FEATURE2 → FEATURE1:

CREATE OR REPLACE FEATURES AS
PERSIST
    fm.tutorials.my_overwrite.feature3 := fm.tutorials.my_overwrite.feature2 * 2
;

Override one value

Assign 10 to the fully qualified FEATURE1. FEATURE2 and FEATURE3 then recompute from that query-local value:

RETURN
    fm.tutorials.my_overwrite.feature1 := 10,
    fm.tutorials.my_overwrite.feature2,
    fm.tutorials.my_overwrite.feature3
;

Override several definitions

Several overrides can be tested together. Here, FEATURE1 receives a literal and FEATURE2 receives a new formula:

RETURN
    fm.tutorials.my_overwrite.feature1 := 10,
    fm.tutorials.my_overwrite.feature2 := fm.tutorials.my_overwrite.feature1
    * 10,
    fm.tutorials.my_overwrite.feature3
;

Sweep through bound values

Declare the overridden feature as an INPUT() and bind several candidate values to compare how the dependency chain responds:

RETURN
    fm.tutorials.my_overwrite.feature1 := INPUT(BIGINT),
    fm.tutorials.my_overwrite.feature2,
    fm.tutorials.my_overwrite.feature3
FOR
    fm.tutorials.my_overwrite.feature1 := BIND_VALUES(ARRAY(10, 11, 12))
;

An override must remain type-compatible with downstream formulas. It also must use the fully qualified persisted name: defining an unqualified local feature with the same short name does not replace persisted dependencies.

When the tested definition is ready to share, publish it with CREATE OR REPLACE. Until then, every override disappears with the query.

A DEFINE / RETURN assignment overrides a name inside one RETURN. Use CREATE TEMPORARY when you need DROP TEMPORARY or several overlay mutations before a result — Statement tools .

Next

Read Registry consistency before publishing a replacement, or return to Explore features to inspect its downstream impact. The RETURN syntax reference lists every query clause and modifier.