Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E0C06633157 for ; Thu, 25 Mar 2010 13:56:07 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 38708-06 for ; Thu, 25 Mar 2010 16:55:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 6D692632817 for ; Thu, 25 Mar 2010 13:55:57 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o2PGtsEH020125; Thu, 25 Mar 2010 12:55:54 -0400 (EDT) To: Greg Stark cc: Louis-David Mitterrand , pgsql-sql@postgresql.org Subject: Re: Does IMMUTABLE property propagate? In-reply-to: <407d949e1003250905m323c6959wd07b0d7310cd271c@mail.gmail.com> References: <4B91C184.4090906@venaver.info> <407d949e1003060645i408e0648te67dfd722172f76a@mail.gmail.com> <4B927FED.60209@venaver.info> <4150.1267911115@sss.pgh.pa.us> <20100325061616.GA4629@apartia.fr> <162867791003250027q3cfc5ba9g59d56768aa4c4e5e@mail.gmail.com> <20100325075405.GA17176@apartia.fr> <16800.1269527726@sss.pgh.pa.us> <407d949e1003250905m323c6959wd07b0d7310cd271c@mail.gmail.com> Comments: In-reply-to Greg Stark message dated "Thu, 25 Mar 2010 16:05:34 -0000" Date: Thu, 25 Mar 2010 12:55:54 -0400 Message-ID: <20124.1269536154@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/190 X-Sequence-Number: 33897 Greg Stark writes: > On Thu, Mar 25, 2010 at 2:35 PM, Tom Lane 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