Re: UPDATE is not allowed in a non-volatile function - Mailing list pgsql-hackers

From Robert Treat
Subject Re: UPDATE is not allowed in a non-volatile function
Date
Msg-id 200411032143.38045.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: UPDATE is not allowed in a non-volatile function  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: UPDATE is not allowed in a non-volatile function  (Thomas Hallgren <thhal@mailblocks.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: modifying a TupleTableSlot
Next
From: Bruce Momjian
Date:
Subject: Re: plans for bitmap indexes?