From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Division by zero |
Date: | 2009-08-02 15:56:11 |
Message-ID: | 20090802155611.GS5407@samason.me.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Aug 02, 2009 at 05:22:45PM +0200, Pavel Stehule wrote:
> 2009/8/2 Sam Mason <sam(at)samason(dot)me(dot)uk>:
> > 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Alexy Khrabrov | 2009-08-02 16:02:41 | Re: building a binary-portable database |
Previous Message | Pavel Stehule | 2009-08-02 15:22:45 | Re: Division by zero |