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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
