Tom Lane wrote:
Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
