tp: pass the SQL a pipeline reads to it as dataframes

[LalitMaganti]

A pipeline ran its SQL sources itself, as statements of their own. So they could see nothing of the statement the pipeline was written in.

Now SQLite evaluates each relation a pipeline reads where the pipeline is written, and builds it into a dataframe, exactly as a PERFETTO TABLE is built. The dataframes are gathered into one list, passed to the pipeline after its plan, and the pipeline reads each like any other dataframe. A pipeline never runs SQL itself, and a plan never holds SQL.

-- FROM (SELECT id, parent_id, self FROM tree) |> TREE ACCUMULATE UP SUM(self) AS total
-- becomes:
SELECT c0 AS "id", ... FROM __intrinsic_pipeline(
  X'<plan>',
  __intrinsic_dataframes(
    (SELECT __intrinsic_dataframe_agg('id,parent_id,self', "id", "parent_id", "self")
     FROM (SELECT id, parent_id, self FROM tree))))

How:

• __intrinsic_dataframe_agg builds a dataframe of a relation's rows with the same builder CREATE PERFETTO TABLE uses, and passes it to SQL as a "TABLE" pointer, like other functions returning dataframes. It skips the builder's analysis (integer downcasting, sort detection, distinct-count statistics), as a pipeline only scans the result.
• __intrinsic_dataframes gathers them into one list argument, so the table function has a single hidden column for them however many relations a pipeline reads.
• A plan reads its i-th SQL source as dataframe argument i. When the plan is loaded, each argument is bound to the dataframe passed, taking its column types from it, so lowering only ever sees dataframes: no new source or storage type.
• The columns of a relation come from semantic analysis rather than from preparing its SQL: dataframes and views as before, and other tables SQLite knows (including table functions) by their schema. Anything else, like VALUES, fails clearly for now.
• Anyone can write a plan and its arguments into SQL, so binding checks each argument has the columns the plan reads.

Removes: SqlScan (and all of perfetto_sql/exec), DescribeQuery, positional pruning of SQL sources, and the string pool lowering needed.

Behaviour changes, on purpose:

• As in a PERFETTO TABLE, a column read from SQL must hold one type throughout.
• Duplicate or unnamed columns are reported from the source as written, not as SQLite renamed them.

This is what lets pipelines become subqueries later in the stack: their SQL then simply runs in the statement around them.

[github-actions]

🎨 Perfetto UI Builds & Tests

• b0588e6 (2026-09-27 20:32 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36346786269-1-ui/ui/index.html
• d062d6d (2026-09-27 21:07 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36349076940-1-ui/ui/index.html
• 1a94318 (2026-09-27 21:26 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36350899280-1-ui/ui/index.html
• ❌ Playwright tests failed: test report
• 35656c1 (2026-09-27 23:16 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36356957951-1-ui/ui/index.html
• ❌ Playwright tests failed: test report
• 27a3c9d (2026-09-27 23:42 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36358497959-1-ui/ui/index.html
• 128f136 (2026-09-27 23:56 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36359743954-1-ui/ui/index.html
• 22ec1cd (2026-09-28 04:15 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36375499664-1-ui/ui/index.html
• b408fcb (2026-09-28 05:17 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36377378881-1-ui/ui/index.html
• ce2a86a (2026-09-28 05:46 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36382037981-1-ui/ui/index.html
• 0999913 (2026-09-28 06:28 UTC): https://storage.googleapis.com/perfetto-ci-artifacts/gh-36384805295-1-ui/ui/index.html