Re: [pgsql-hackers] UPDATE is not allowed in a non-volatile function

Josh Berkus wrote:
> Gaetano,
> 
> 
>>I do not consider my design as "unsafe", this is for example how a
>>cache works: expose a "read" without side effect but updating internal
>>statistics. After all the read will not alter the data that it expose
>>but other data that the user even don't know the existence.
> 
> 
> At issue is the working definitions of the function states (and yes, I know 
> these aren't the formal definitions but these are what is useful):
> IMMUTABLE: result of function will always be the same given the same inputs;
> STABLE: result of function will be the same for the duration of the 
> transaction.
> VOLATILE: you can't count on any particular result based on the inputs
> 
> Any function involving an UPDATE -- and I write a LOT of them -- clearly falls 
> into the last group.   You never know what you're going to get as a result of 
> an UPDATE; you could get an index violation, a lock wait, a deadlock, a 
> constraint violation, etc.    

Do this means that an IMMUTABLE function is free of errors (nothrow) ?
You can fire a deadlock also calling an IMMUTABLE function.

As you wrote:

IMMUTABLE: result of function will always be the same given the same inputs;

and my "read" satisfy this definition: the result is the same given the same inputs,
but also performs update statistics that will not interfere with the data exposed.

I think avoid an IMMUTABLE function perform update is a big limit and fortunatelly
the limit is no so big given the fact that a function marked as  IMMUTABLE can call
a function marked as VOLATILE ( that IMHO is not so good... ).


Regards
Gaetano Mendola