On Sun, Aug 02, 2009 at 05:22:45PM +0200, Pavel Stehule wrote: > 2009/8/2 Sam Mason <sam@xxxxxxxxxxxxx>: > > On Sun, Aug 02, 2009 at 02:20:18PM +0200, Pavel Stehule wrote: > >> There is paradox - IMMUTABLE function break inlinig :(. There is maybe bug > > > > Not in any tests I've done. > > I did it - and in this case immutable is wrong and strict not. I'm not sure what you're responding to here, but I'm pretty sure the OP wants IMMUTABLE and does not want STRICT/RETURNS NULL ON NULL INPUT. > It's an > new for me, because I used rules that are well only for plpgsql or C > language. What I see now, the rules for sql are totally different. SQL language functions are going to be different from anything else because the can be. The planner has intimate knowledge of SQL and hence will try hard to expand these out and optimize them (in a similar way to how it handles views). The semantics of these keywords shouldn't change between SQL, plpgsql and C functions though, it's just that the optimizer can look inside an SQL function and not other functions. Maybe if you can say what you did and what result you got back? -- Sam http://samason.me.uk/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
