Pinot connector: column index for ... was not found

[sumit-gupta-sgt]

Description:
Using Pinot passthrough queries in Trino 479, column aliases e.g., 'No. of msg' are no longer recognized. The same query works in Trino 446.

SELECT *
FROM "SELECT user, SUM(msg) AS 'No. of msg'
      FROM test
      WHERE p_date >= ToDateTime(ago('P29D'),
                               concat(concat('yyyy-', UPPER('MM'),''),'-dd',''))
        AND id IN ('xx')
      GROUP BY 1
      ORDER BY 2 DESC
      LIMIT 300";

Expected behavior (Trino 446):

• Query executes successfully.
• Column alias 'No. of msg' is recognized/displayed.

Actual behavior (Trino 479):

• Fails with:

Query failed: column index for 'no. of msg' was not found

• Alias cannot be referenced; Trino ignores Pinot passthrough column names.

Environment:

• Trino 479 (failing)
• Trino 446 (working)
• Pinot connector

Severity: High — backward compatibility broken for Pinot passthrough queries relying on aliases.

[ebyhr]

@sumit-gupta-sgt Can you find the first bad version with bisect?

[sumit-gupta-sgt]

@ebyhr We tried upgrading to 479, but testing all releases from 446 to 479 via bisect is hard, especially since it would require additional customizations and setup for each Trino version to test properly.

[sumit-gupta-sgt]

Update

Further testing shows that this issue occurs when the Pinot passthrough query returns an empty result set, and it reproduces in both Trino 446 and Trino 479.

When the underlying Pinot query returns rows, the column alias (e.g., 'No. of msg') is recognized correctly. However, when the result set is empty, the query fails with:

Query failed: column index for 'no. of msg' was not found

Behavior Summary

• ❌ Trino 446 – Fails when result set is empty
• ❌ Trino 479 – Fails when result set is empty
• ✅ Both versions work when the Pinot query returns rows
• 🔎 Issue only reproducible for empty result sets

Conclusion

This is not a regression in Trino 479.
The issue is specifically related to how Pinot passthrough queries handle column metadata when no rows are returned.

Severity should be reassessed since this does not represent a backward compatibility break between versions, but rather a behavior triggered by empty result sets.