On Thu, 2011-09-22 at 07:50 -0500, Merlin Moncure wrote: > On Thu, Sep 22, 2011 at 5:28 AM, Rafal Pietrak <rafal@xxxxxxxxxxxxxxxxxx> wrote: > > if you change the state of the database, including (and especially) > system catalogs, your function is volatile, period. Hmmm. To quote from the online documentation: "VOLATILE indicates that the function value can change even within a single table scan" this funciton return value does not change. Further we read: "any function that has side-effects must be classified volatile, even if its result is quite predictable, to prevent calls from being optimized away;" 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)? On Thu, 2011-09-22 at 10:05 -0400, Tom Lane wrote: Rafal Pietrak <rafal@xxxxxxxxxxxxxxxxxx> writes: > > but I get: > > ERROR: ALTER ROLE is not allowed in a non-volatile function > > Why??? > > Because non-volatile means, among other things, "this function has no > side effects". > > regards, tom lane Still, those side efects are "stable" - meaning (in a particular case of that function) for the same input, thay are always the same..... withoun a transaction could possibly by optimized away. Then again, with postgres 9.1 I'd write a "RULE ... WITH user (uid) as (SELECT mypass() as uid) SELECT ... FROM user ..." that would do the expected optimization explicitly. This would work, right? And the optimization of a STABLE function within a query, triggers just that, right? So why to raise and ERROR? -R -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
