Обсуждение: Re: [ADMIN] concat_ws

Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> It seems to be running out of memory.

> Also worth noting, without STRICT, even a plain EXPLAIN *without*
> ANALYZE causes the problem to show itself.

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.

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?

Your definition of concat_ws bears some passing resemblance to the
infamous Ackermann's function, btw.

            regards, tom lane

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

Joe Conway <mail@joeconway.com> writes:
> But I wonder why it isn't at all a problem when the function is also
> defined STRICT?

Because the inliner doesn't think it can safely inline in that case; the
substituted expression isn't strict and so inlining would potentially
change the semantics.

            regards, tom lane