On Thu, 2011-09-22 at 16:57 +0200, Szymon Guz wrote:
>
>
> On 22 September 2011 16:29, Rafal Pietrak <rafal@zorro.isa-geek.com>
> wrote:
[----------]
>
> Well. In this caase, I'd like it being optimised away. This is
> the
> expected result. And the above documentation fragment states
> it as only
> a precausion, not an ERROR.
>
> Are there other reasons for that ERROR (e.g. not a warrning)?
>
>
> Yes, the reason is that caching that function could be a problem.
I only could guess here, that caching is taking the function fingerprint
(e.g. name+arg-types) as key with result as value ... saved after first
call when function is stable. This does not sound inapropiate or
difficult in such cases. But naturally, I don't know the real internals,
so I admit, there may be a problem here.
>
> And why do you want to optimize that?
Currently it's 10k users, I have to plan for 100k. Haveing system table
updated this many times for every password change is not too friendly to
a database.
> Does it take too much time, or do you want to call that thousands of
> times?
...but on the other hand, passwords changes don't happen that often....
so performence will not suffer much.
> Have you checked how much the function lasts?
No, It's just that I don't like to build a systems that issues database
updates when those are not really necesary.
>
>
But I undestand that the overall conclusion is that sideeffects are
volatile no matter what (and the more relaxed statements in the
documentation should not be taken as and invitation to experiment :).
Thank you all for the feedback
-R
