What causes "No table argument found for name: " in prestodb/presto?

Match the copartitioning name exactly to a table argument name in the same invocation.

prestodb/presto · error · SemanticException

TABLE_FUNCTION_INVALID_COPARTITIONING

TABLE_FUNCTION_INVALID_COPARTITIONING

Error message

No table argument found for name:

What it means

A COPARTITIONING clause named a table argument that does not exist among the table arguments of the current table function invocation (after qualifying the name against catalog/schema). The analyzer looks up the referenced name in the map of qualified table-argument inputs and throws TABLE_FUNCTION_INVALID_COPARTITIONING when the candidate set is empty.

Source

Thrown at presto-main-base/src/main/java/com/facebook/presto/sql/analyzer/StatementAnalyzer.java:2277

            Set<String> referencedArguments = new HashSet<>();
            for (List<QualifiedName> nameList : copartitioning) {
                ImmutableList.Builder<TableArgumentAnalysis> copartitionListBuilder = ImmutableList.builder();

                // resolve copartition tables as references to table arguments
                for (QualifiedName name : nameList) {
                    Collection<TableArgumentAnalysis> candidates = emptyList();
                    if (name.getParts().size() == 1) {
                        // try to match unqualified name. it might be a reference to a CTE or an aliased relation
                        candidates = unqualifiedInputs.get(name);
                    }
                    if (candidates.isEmpty()) {
                        // qualify the name using current schema and catalog
                        // Since we lost the Identifier context, create a new one here
                        QualifiedObjectName fullyQualifiedName = createQualifiedObjectName(session, new Identifier(name.getOriginalParts().get(0).getValue()), name, metadata);
                        candidates = qualifiedInputs.get(QualifiedName.of(fullyQualifiedName.getCatalogName(), fullyQualifiedName.getSchemaName(), fullyQualifiedName.getObjectName()));
                    }
                    if (candidates.isEmpty()) {
                        throw new SemanticException(TABLE_FUNCTION_INVALID_COPARTITIONING, name.getOriginalParts().get(0), "No table argument found for name: " + name);
                    }
                    if (candidates.size() > 1) {
                        throw new SemanticException(TABLE_FUNCTION_INVALID_COPARTITIONING, name.getOriginalParts().get(0), "Ambiguous reference: multiple table arguments found for name: " + name);
                    }
                    TableArgumentAnalysis argument = candidates.stream().collect(onlyElement());
                    if (!referencedArguments.add(argument.getArgumentName())) {
                        // multiple references to argument in COPARTITION clause are implicitly prohibited by
                        // ISO/IEC TR REPORT 19075-7, p.33, Feature B203, “More than one copartition specification”
                        throw new SemanticException(TABLE_FUNCTION_INVALID_COPARTITIONING, name.getOriginalParts().get(0), "Multiple references to table argument: %s in COPARTITION clause", name);
                    }
                    copartitionListBuilder.add(argument);
                }
                List<TableArgumentAnalysis> copartitionList = copartitionListBuilder.build();

                // analyze partitioning columns
                copartitionList.stream()
                        .filter(argument -> !argument.getPartitionBy().isPresent())
                        .findFirst().ifPresent(unpartitioned -> {

View on GitHub (pinned to 55bb57d202)

Solutions

Match the copartitioning name exactly to a table argument name in the same invocation.
Use the same qualification level (either both qualified or both simple names).
Remove stale references left over from renaming arguments.
Confirm each referenced relation is actually passed as a table argument, not just present in the query.

Example fix

// before
TABLE(join_fn(l => orders, r => customers) COPARTITIONING (orders, cust))

// after
TABLE(join_fn(l => orders, r => customers) COPARTITIONING (l, r))

Defensive patterns

Strategy: validation

Validate before calling

// Ensure every COPARTITIONING name matches a table argument in the same invocation
Set<String> argumentNames = tableInvocationArguments.keySet(); // e.g. {"l", "r"}
for (String name : copartitioningNames) {
    String simple = name.contains(".") ? name.substring(name.lastIndexOf('.') + 1) : name;
    if (!argumentNames.contains(simple)) {
        throw new IllegalArgumentException("COPARTITIONING references unknown table argument: " + name);
    }
}

Prevention

Reference table arguments by their argument alias, not the underlying table name.
Keep qualification of copartitioning names consistent with the argument names.
Re-check the COPARTITIONING list after renaming any table arguments.

When it happens

Trigger: Writing COPARTITIONING(a, b) where 'b' (or its qualified name) does not match any table argument name passed in the same TABLE(...) invocation, or the qualifier (catalog/schema/table alias) does not resolve.

Common situations: Typos in the copartitioning names; referencing the underlying table name instead of the argument alias; using an unqualified name when the argument was registered under a qualified name, or after renaming an argument.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/2db8e9e87dd11c4a. Report an issue: GitHub.