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
