下一階段｜增加 SQL 靈活性

目前還差什麼

本版 Agent 能選條件，但還不能自行改變 JOIN、GROUP BY 或計算指標。若要回答「各客戶今年每月的未出貨量排行」，必須新增受控能力；不能假裝現有 query_orders 已經支援。

建議的兩階段擴充

階段	如何增加能力	必須保留的邊界
受控查詢規格	加入 dimensions、metrics、filters，服務把合法組合編成 SQL	型別、語意、欄位與租戶授權
受限動態 SQL	Agent 在核准的 view／欄位／函式內產生查詢	AST 驗證、最小權限、RLS、資源與輸出限制

受控規格通常比大量固定工具更有彈性，也較容易測試。確實需要 SQL 自由度時，再提供獨立的進階工具；讓工具名稱與風險範圍清楚可見。

動態 SQL 的最低設計工作

1. 給模型的 schema 僅包含已授權的資料與業務定義，不提供整庫機密欄位。
2. 使用 PostgreSQL 相容 parser 檢查 AST；不以字串含有 SELECT 作為安全證明。需處理多陳述式、可寫 CTE、函式副作用與系統目錄存取。
3. 真正執行時使用非 owner、非 superuser、無 BYPASSRLS 的唯讀角色；檢查所有可呼叫函式與 SECURITY DEFINER 路徑。
4. 以交易層設定 readonly、statement_timeout、lock_timeout，限制結果筆數與位元組；執行後仍檢查結果。
5. 為昂貴 JOIN／排序／聚合設定資源界線與併發額度。EXPLAIN 只能輔助估算，不能保證成本；不要對未知查詢先跑 EXPLAIN ANALYZE。
6. 設累計查詢／匯出預算、可信授權上下文與必要核准。每頁 50 筆不能阻止連續大量分頁。
7. 預先準備注入、跨部門、跨租戶、超時、秘密外洩與資料錯誤題庫。

上述是設計與待驗收工作，尚未部署成任意 SQL 端點。

效率從哪裡改善

讓 PostgreSQL 執行篩選、聚合與排序；給模型的資料只含回答需要的欄位。依實際查詢計畫調整索引與統計資訊。用有限併發與超時避免慢查詢拖垮其他學員。

需要連線池時，必須處理短效帳號到期、撤銷與租戶上下文。PgBouncer 不會自動替你完成授權，也不能把過期帳號的舊連線無限重用。

來源：PostgreSQL RLS、權限。