2009/8/2 Sam Mason <sam@xxxxxxxxxxxxx>: > 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. > I checked if function was inlined or not. When I mark function as strict then it was inlined. When I mark function as IMMUTABLE then it wasn't inlined. That's all - you can check it too. >> 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 > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
