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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
