All Known Implementing Classes:: UnresolvedExternalRelation, UnresolvedRelation

public sealed interface UnresolvedSourceRelation permits UnresolvedRelation, UnresolvedExternalRelation

Marker for the unresolved leaf plans the parser produces for FROM-style source commands. The interface is sealed: every shape must be listed in the permits clause, so adding one is a compile-time decision rather than a silent drift. Today there are two shapes:

UnresolvedRelation — the index-pattern path (FROM <index>, TS, etc.).
UnresolvedExternalRelation — the external/dataset path (FROM <dataset> and inline EXTERNAL).

This is a pure marker with no methods. The two implementations expose different "primary identifiers" (UnresolvedRelation.indexPattern() returns an IndexPattern, UnresolvedExternalRelation.tablePath() returns an Expression), so there is no clean common accessor to extract. The marker exists solely so a traversal that wants any FROM-style leaf can match on instanceof UnresolvedSourceRelation (or Class.isInstance(java.lang.Object)) instead of enumerating the concrete classes and silently drifting whenever a new shape is added.

Note this is a plain interface, not a LogicalPlan subtype, so it cannot be passed to the typed forEachUp(Class, Consumer) / transformUp(Class, ...) overloads (those require a LogicalPlan bound). Match it with an instanceof test inside a plain forEachUp(Consumer) / collect(Predicate) traversal instead.

Adding a new traversal site? Decide deliberately whether it should fire on every source shape or only one:

If it cares about any FROM-style leaf (e.g. pre-analysis schema/field collection), match on this marker. Cast to the concrete type inside the handler if you need a shape-specific accessor.
If it is genuinely specific to one shape (e.g. index resolution, time-series-mode detection, view resolution), keep matching the concrete class. The shape-specific accessor it calls — indexMode(), indexPattern(), metadataFields(), etc. — already signals the intent; only add a comment where the single-shape choice is not self-evident from the surrounding code.

See Also:

Interface UnresolvedSourceRelation