Hi,
Aggregate UDF's are nice, but I think it's a mistake to think about them
only in classic COUNT(), AVG(), SUM() etc. context. Why we don't look at
them in more general way?
Aggregates loop over input set and produce single value. Right now we do
UDF-like aggregates inside PSQL SP using FOR SELECT loops or CURSORs.
Moving the cursor definition up from SP/Func body to the caller would
not only extend the flexibility of this aggregating procedures, but
would allows seamless integration into GROUP BY and other contexts
suitable for aggregation tasks.
If we would introduce new parameter type -> the cursor, it would be
perfect fit for enhanced FOR loop that could accept the cursor variable
instead literal SQL statement. No need for SUSPEND, the UDF execution
would be self-contained and with single invocation within given context.
The input parameter could be provided by engine (as part of group by or
other processing) or other UDF (we can already create cursors in PSQL
using DECLARE CURSOR, and if we would extend it to allow creation of
unassigned cursor variable and the possibility to store the EXECUTE
STATEMENT handle into such CURSOR variable, it could be even more
powerful). That way it could be easily comprehended general feature with
simple rules and methods of invocation that could be used in various
contexts and for various purposes.
Aggregates could produce various single-value outputs, for example
frequency distributions using an array, percent represented by string
(number of # in fixed count of chars, as literal string etc.), they
could produce hashes, JSON packets, URI path names etc.
best regards
Pavel Cisar
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
