On 1/8/2025 00:56, Michael Paquier wrote:
On Thu, Jul 31, 2025 at 11:52:59AM -0500, Sami Imseih wrote:
This means that the configuration parameter (GUC) currently overrides
any explicit request for a plan type. The documentation does not clearly
explain the rationale behind this, at least to me.
The documentation [0] mentions " If this default behavior is
unsuitable, you can alter it by
passing the CURSOR_OPT_GENERIC_PLAN or CURSOR_OPT_CUSTOM_PLAN flag to
SPI_prepare_cursor". The default behavior here is plan_cache_mode = AUTO.
But the docs leave out the fact that is plan_cache_mode is not AUTO, that the
GUC settings take precedence over the cursor_options. I agree as well that is
wrong. I also agree with your fix.
[0] https://www.postgresql.org/docs/current/spi-spi-prepare.html
It seems to me that if we want to keep track of the priority of the
GUC versus the options given to the SPI call, then we should at least
have some tests for this purpose. I would imagine a test module with
a set of SQL functions that act as wrappers of the SPI calls we want
to test, and arguments that can be given directly in input, using
PG_GETARG_POINTER and PG_RETURN_POINTER for some of them.
I'm not sure I understand it clearly. You propose to transfer some
internal data, let's say SPIPlanPtr, between different UDFs?
Reading the documentation, I see that SPI is intended to be used inside
a UDF. For example, the SPI_connect routine 'connect a C function to the
SPI manager'.
I am afraid that this mechanism is not ready to survive a function
context switch safely. Or do you mean it is ok to restrict test coverage
to only the 'saved' statements?
--
regards, Andrei Lepikhov
