On Thu, 2011-09-22 at 07:50 -0500, Merlin Moncure wrote:
> On Thu, Sep 22, 2011 at 5:28 AM, Rafal Pietrak <rafal@zorro.isa-geek.com> 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@zorro.isa-geek.com> 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
