Re: UPDATE is not allowed in a non-volatile function

Gaetano,
>
> I do not consider my design as "unsafe", this is for example how a
> cache works: expose a "read" without side effect but updating internal
> statistics. After all the read will not alter the data that it expose
> but other data that the user even don't know the existence.
>
> However I think that "that missing check" is "unsafe" and jeopardize the
> effort to avoid a wrong user design.
>
> Having say that I'm happy to know that what I did will continue to work
> splitting the function in two parts.
>
I think Gaetano has a point but I consider the solution somewhat kludgy.
The Rationale for my opinion is that since there is a need to accomplish
what Gaetano needs, there should be declarative power to express it and
thus, prevent "unsafe" designs. We need a way to declare a function
"stable with no _intrusive_ side effects". It's far better to explicitly
state this then to rely on a flaw of the current function calling mechanism.

The current read-only status, maintained and passed to the SPI execute
functions by function developers themselves, is not good enough. There
are two main reasons for this:
a) Nesting is not accounted for. The correct behavior should be to block
all nested volatile calls as soon as a function declared non-volatile is
called. I can of course enforce this within the PL/Java domain but I
have no control over functions written in other languages.
b) The responsability to maintain the read-only flag should not be
pushed onto the function developers. It's fully possible for the
PostgreSQL calling mechanism to maintain some global structure that is
updated prior to calling functions and then for the SPI functions to
consult that structure.

Regards,
Thomas Hallgren