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.
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.
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
