On Thu, 2011-09-22 at 16:57 +0200, Szymon Guz wrote: > > > On 22 September 2011 16:29, Rafal Pietrak <rafal@xxxxxxxxxxxxxxxxxx> > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
