Tom,
What you think is non-intrusive may not be so at the database's level.
I know. But thats not my point. Look at this this way:
I'd like to declare a function STABLE. And I'd like to trust that declaration 100%. So a stable function must *never* call a function that is VOLATILE. Not directly and not implicit through nesting.
I think we agree that the current way of enforcing that protection can't be trusted. As a function developer you really need to know what you are doing and take great care not to call a volatile function from within a stable or immutable function. The system won't protect you at all.
My suggestion is first and foremost an attempt to enforce the procection and make the STABLE declaration really mean something so that all users can benefit from this and be able to rely on the concept. So far, no mention of non-intrusive. I'd really like your opinion on this part as a separate issue.
Now, some people, like Gaetano, might want to go further and do things that are beyond what PostgreSQL can provide 100% protection for. They *want* to take on the responsability themselves. That's where my new function characteristic with "non-intrusive" comes in. I admitt that "non-intrusive" might be a bad term for this. What I mean is a characteristic that overrides my suggested 100% reliable interpretation of STABLE. This characteristic is not intended for the everyday function developer and should be documented as such.
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
