Christian Fritze <The.Finn@sprawl.de> writes:
> create aggregate test_agg_1 (
> basetype = text,
> stype1 = text,
> sfunc1 = textcat,
> initcond1 = '');
> and then selecting like
> select test_agg_1(textvar || ' ') from testtable;
> perfectly suites my needs. Sorry for the fuzz!
> Still I'm somewhat curious as to why my first
> approach didn't work...
The difference is that textcat is a built-in function (C-coded), and
what you were previously trying to supply to CREATE AGGREGATE was an
SQL function. The function manager is currently quite paranoid about
allowing SQL functions to be invoked from arbitrary contexts inside the
system; in particular it won't allow one to be called from the aggregate
executor.
This restriction is probably overly conservative, but it's not
completely without foundation. For example, imagine defining an index
whose sort order depends on an SQL function, and then make the SQL
function be one that queries, or even worse updates, the table the index
is on. Is that gonna work? Nyet: it'll lead to infinite recursion,
crash and burn. So for the moment I'd rather see the code err on the
side of caution. Eventually we need a more sophisticated execution
model that can catch such recursive loops directly, and then we can
allow the normal non-recursive cases without fear.
regards, tom lane