I once resolved an issue involving Cursor, so I’ve done some research in this area before. I think you're right that CURSOR isn't usable for UDFs currently, but the reason differs depending on the kind of UDF: 1. Scalar/aggregate UDFs: intentional restriction. CURSOR is a table-valued concept and is only valid inside FROM TABLE; it's explicitly rejected in scalar positions (FamilyOperandTypeChecker, ProcedureNamespace); 2. Table UDFs: no architectural barrier just unimplemented. Validation/type inference already support a CURSOR arg, but execution isn't wired up (TableFunctionTest cursor tests are @Disabled with CannotPlanException).
On 2026/07/09 13:56:49 ткаленко кирилл wrote: > As far as I understand, CURSOR is not currently supported for UDF. > Are there any objections to this? Are there any fundamental or architectural > reasons for this? >
