|
Hello, when defining functions, why can’t they take table-valued
arguments? I do not see the sense of this restriction. When a function takes a
table as an argument, whole tables could be transformed in an obvious way. Currently
functions must operate row-wise (at least I haven’t found another way). This
also limits the capabilities of joining the row-arguments, obviously this must
be done before passing the arguments to the functions, instead of having one or
more table-arguments and simply doing the joins within the function. Further,
table valued arguments could lower the developer’s work to prepare the
arguments before the function call and enabling each functions to care for them
itself by transforming them for the implementation instead of introducing
several more or less anonymous record types just for passing values from one
function to another which often also carry implementation specific constraints.
The structure of the code as a set of functions would also greatly improve. What does the optimizer do with this per-row-semantic, even if it is
invoked on each row? Does it transform the queries within the function to
directly work on the table and realize possible advantages from indexes and
other techniques? -- Kind
Regards, Robert |
