Re: Re: going gaga on creating an aggregate... [solved of course...]
От | Tom Lane |
---|---|
Тема | Re: Re: going gaga on creating an aggregate... [solved of course...] |
Дата | |
Msg-id | 26648.955861450@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: going gaga on creating an aggregate... [solved of course...] (Christian Fritze <The.Finn@sprawl.de>) |
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: