Thread: Re: going gaga on creating an aggregate... [solved of course...]

Oh my, I've been obfuscating. Again...
While having a couple of beers as mental lubricants in the 
LAP (Local Area Pub), it came to my mind that just doing a 
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...


Greetings
Christian


-- 
"The sky above the port was the color of television,tuned to a dead channel."                                        --
W.G.--
 

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