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

On Wednesday 03 November 2004 18:06, Thomas Hallgren wrote:
> 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.
>

I think the guidelines are fairly clear on what types of functions should be
declared with which types. But the key is that these are guidelines, not hard
and fast rules, since there may be times when you need to ignore them.

> 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.
>

"users" shouldn't care. the function developer should determine the details
and "users" shouldn't have to think about it.

> 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.
>

Well, personally I prefered the way thing worked in 7.4, but I'm willing to
live with the 8.x method. If you forcibly prevent the work around though,
you better provide a work around, and if that mean a fourth function type I
could live with that; it's certainly better than marking these types of
functions volitile, which is a non-starter in my application.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL