Tom Lane wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
>
>> 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?
>>
>
> That case is fine. The problem would be in calling, say, VOLATILE from
> STABLE. Any SPI queries executed inside the VOLATILE function would
> need to be handled under read-write not read-only rules.
>
> Now it's perhaps possible for you to track that yourself and make sure
> to call SPI with the right arguments for the type of function you're
> currently in, even if you didn't get to it via the front door. But
> that's a far cry from "ignoring" the volatility property. It seems
> nontrivial to do if you try to set things up so that no plperl code is
> executed during the transition from one function to another.
>
>
I don't understand that phrase "call SPI with the right arguments for
the type of function you're currently in". What calls that we make from
plperl code would have different arguments depending on the volatility
of the function? If a cached plan is going to behave differently, I'd be
inclined to say that we should only allow direct inter-sp calling to
volatile functions from volatile functions - if U understand you right
the only problem could be caused by calling in this direction, a
volatile function calling a stable function would not cause a problem.
That is surely the most likely case anyway. I at least rarely create
non-volatile plperl functions, apart from an occasional immutable
function that probably shouldn't be calling SPI anyway.
cheers
andrew