Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>
>
>> OK, but won't that automatically supply the value from the function
>> called from postgres, which will be the right thing?
>>
>
> My point was that that is exactly the wrong thing. If I have a function
> declared stable, it must not suddenly start behaving as volatile because
> it was called from a volatile function. Nor vice versa.
>
> Now as I mentioned upthread, there might be other ways to get the
> correct value of the readonly parameter. One that comes to mind is
> to somehow attach it to the spi call "at compile time", whatever that
> means in the perl world. But you can't just have it be determined by
> the outermost active function call.
>
>
>
OK.
Well, no doubt Tim might have better ideas, but the only way I can think
of is to attach a readonly attribute (see perdoc attributes) to the
function and then pass that back in the SPI call (not sure how easy it
is to get the caller's attributes in C code). Unless we come up with a
neatish way I'd be a bit inclined to agree with Robert that this is all
looking too complex.
Next question: what do we do if a direct-called function calls
return_next()? That at least must surely take effect in the caller's
context - the callee won't have anywhere to stash the the results at all.
cheers
andrew