On Tue, Jan 05, 2010 at 06:54:36PM -0500, Tom Lane wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
> > On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
> >> Definite benefit, there. How does it handle the difference between
> >> IMMUTABLE | STABLE | VOLATILE, as well as STRICT functions?
>
> > It doesn't at the moment. I think IMMUTABLE, STABLE and VOLATILE can be
> > (documented as being) ignored in this context.
>
> Just for the record, I think that would be a seriously bad idea.
> There is a semantic difference there (having to do with snapshot
> management), and ignoring it would mean that a function could behave
> subtly differently depending on how it was called. It's the kind of
> thing that would be a nightmare to debug, too, because you'd never
> see a problem except when the right sort of race condition occurred
> with another transaction.
>
> I see downthread that you seem to have an approach without this gotcha,
> so that's fine, but I wanted to make it clear that you can't just ignore
> volatility.
Ok, thanks Tom.
For my own benefit, being a PostgreSQL novice, could you expand a little?
For example, given two stored procedures, A and V, where V is marked
VOLATILE and both are plperl. How would having A call V directly, within
the plperl interpreter, cause problems?
Tim.