public final class FromSubqueryNaming extends Object
Lives in the binding package so both Resolver2NameBindingProvider
and SemanticIRBuilder (in the builder package) can reach it
without a circular dependency.
The slice-74 decision is to admit FROM subqueries that lack a
written alias, mirroring the parity baseline established by dlineage
(which already accepts these unconditionally). The synthetic alias is keyed
on the parser's start-token position so it is:
l<n>_c<n> suffix make
accidental collisions with hand-written identifiers effectively
impossible.If two anonymous subqueries somehow shared a start token (parser bug),
the existing DiagnosticCode.DUPLICATE_FROM_SUBQUERY_ALIAS
rejecter catches the collision the same way it catches a literal
user-written duplicate alias.
| Modifier and Type | Field and Description |
|---|---|
static String |
SYNTH_PREFIX
Prefix marker for synthetic alias strings; useful for diagnostics.
|
| Modifier and Type | Method and Description |
|---|---|
static String |
effectiveAliasOrNull(TTable t)
Effective alias for any FROM-clause
TTable: the SQL-written
alias if non-empty, else the synthetic alias for unaliased
FROM-subquery TTables, else null. |
static String |
synthAliasFor(TTable t)
Compute the synthetic alias for an unaliased FROM-clause subquery
TTable. |
public static final String SYNTH_PREFIX
public static String synthAliasFor(TTable t)
TTable. The result is keyed on the parser's start-token
line/column. Callers should only invoke this for TTable
nodes whose TTable.getTableType() is
ETableSource.subquery and whose TTable.getAliasName()
is null or empty — but the method is defensive about both.
Returns "__subquery_anonymous__" as a defensive fallback
when the start token is missing (should not happen for a parsed AST).
public static String effectiveAliasOrNull(TTable t)
TTable: the SQL-written
alias if non-empty, else the synthetic alias for unaliased
FROM-subquery TTables, else null. Callers handling base
tables fall back to TTable.getName() when this returns
null.