Greg Stark <gsstark@mit.edu> writes:
> On Thu, Mar 25, 2010 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> When you're intending to have a SQL function be inlined, it's probably
>> best not to mark it as either IMMUTABLE or STRICT --- that doesn't buy
>> anything and it can complicate matters as to whether inlining is legal.
> I'm confused, I thought it was volatile and strict that prevented inlining.
No: we won't inline if the contained expression is more volatile than
what the function is marked as being. This is a hack that prevents the
inlining logic from defeating kluges that people might be using in
certain applications, namely putting "immutable" or "stable" wrapper
functions around functions that are more volatile than that in the eyes
of the system. You can do that to force the planner to treat things as
immutable/stable in certain contexts; but of course the trick wouldn't
work if the inliner opens up the function and exposes its true contents.
But in the other direction, exposing a definition that is less volatile
than the function's declaration cannot break anything.
Similarly, a STRICT marking prevents inlining unless the planner can
prove that the contained expression would act the same as the function
declaration w.r.t. returning null for any null input; and in all but
the simplest cases it can't prove that.
regards, tom lane
