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