Tom Lane wrote:
> Yeah. The problem is that the SQL function inliner generates an
> enormous expression tree from this function definition. 7.3 had no
> inliner so no problem.
But I wonder why it isn't at all a problem when the function is also
defined STRICT?
I also looked back at the greatest() example -- similar behavior. If
defined
...language sql;
or
...language sql IMMUTABLE STRICT;
it works great.
But when defined
...language sql IMMUTABLE;
it dies a horrible recursive death.
In case 1 above, the function doesn't get inlined at all, right? But in
both case 2 and 3, it should get inlined -- why does 2 work fine when 3
doesn't?
> I am not sure what to do about it --- the only idea that comes to mind
> is to put an arbitrary limit (of, say, 5 or 10 function calls) on the
> depth of inlining expansion. That seems like a pretty ugly answer
> ... anyone have a better one?
But as above, case 2 is inlined (I think) and works fine -- why restrict it.
> Your definition of concat_ws bears some passing resemblance to the
> infamous Ackermann's function, btw.
I always knew I was destined to be infamous ;-)
Joe
