{"record":{"id":"12a3a4beb2ce4972","repo":"clockworklabs/SpacetimeDB","slug":"could-not-compute-positional-arguments-during-quer","errorCode":null,"errorMessage":"Could not compute positional arguments during query planning","messagePattern":"Could not compute positional arguments during query planning","errorType":"validation","errorClass":"anyhow::Error","httpStatus":null,"severity":"error","filePath":"crates/physical-plan/src/plan.rs","lineNumber":546,"sourceCode":"                        ..\n                    },\n                    _,\n                )\n                | Self::HashJoin(\n                    HashJoin {\n                        rhs_field: TupleField { label_pos: None, .. },\n                        ..\n                    },\n                    _,\n                ) => {\n                    unresolved_name = true;\n                }\n                _ => {}\n            };\n        });\n\n        if unresolved_name {\n            bail!(\"Could not compute positional arguments during query planning\")\n        }\n\n        Ok(optimized)\n    }\n\n    /// If a view has private arguments, its backing table has an `arg_hash` column.\n    /// This column tracks which rows belong to which argument tuple.\n    ///\n    /// As a result, queries over views cannot read the entire backing table.\n    /// They must only select the rows corresponding to the view arguments used\n    /// by each view reference. Hence we must add an implicit selection over\n    /// these types of views.\n    ///\n    /// Ex.\n    /// ```sql\n    /// SELECT * FROM my_view\n    /// ```\n    ///","sourceCodeStart":528,"sourceCodeEnd":564,"githubUrl":"https://github.com/clockworklabs/SpacetimeDB/blob/6dee26c6efc2856793e12b148a59742964f5d783/crates/physical-plan/src/plan.rs#L528-L564","documentation":"Parameterized views with private arguments are backed by tables with an arg_hash column, and queries over them must be rewritten to select only rows matching the view's argument tuples. When a tuple field in the plan has no label (label_pos: None), the planner cannot map positional arguments to names and bails before optimization completes.","triggerScenarios":"Compiling a query or subscription over a parameterized view whose argument tuple fields cannot be resolved to labels during planning, leaving unresolved_name set.","commonSituations":"Subscribing to argument-parameterized views; changing a view's parameter list; schema/view definitions where arguments are used positionally rather than by name.","solutions":["Declare and reference the view's arguments by name (labeled parameters) instead of positionally.","Query the backing table directly with explicit filters if RLS and permissions permit.","Simplify the view: remove private arguments, or split the view so the problematic projection is not part of the subscribed query."],"exampleFix":"-- before: positional view argument in the subscription\nSELECT * FROM my_view(?);\n\n-- after: named/labeled argument usage\nSELECT * FROM my_view(arg => ?);","handlingStrategy":"validation","validationCode":"-- keep view arguments named and reference them by name:\n--   CREATE VIEW v(x) AS ...;\n--   SELECT * FROM v(arg => ?);   -- ok\n-- avoid positional argument references in subscriptions over parameterized views","typeGuard":null,"tryCatchPattern":"match compile_subscription(&sql, tx, auth) {\n    Err(e) if e.to_string().contains(\"positional arguments\") => {\n        // rewrite using named view arguments or query the backing table\n    }\n    other => other,\n}","preventionTips":["Always label view parameters and use them by name in queries.","Re-test all subscriptions after changing a view's parameter list.","Prefer plain tables over private-argument views in subscription paths."],"tags":["query-planning","views","parameters","subscription"],"backgroundTag":"query-planning-failed","analyzedSha":"6dee26c6efc2856793e12b148a59742964f5d783","analyzedAt":"2026-08-20T06:08:37.179Z","contentChangedAt":"2026-08-20T06:08:37.179Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}