Re: Let plan_cache_mode to be a little less strict - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Let plan_cache_mode to be a little less strict
Date
Msg-id ee429d41-2ea3-43ce-bde9-70475ab4df9c@gmail.com
Whole thread Raw
In response to Re: Let plan_cache_mode to be a little less strict  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 1/8/2025 00:56, Michael Paquier wrote:
> On Thu, Jul 31, 2025 at 11:52:59AM -0500, Sami Imseih wrote:
>> 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.  We could
> also have a function in regress.c, which may be simpler here.  These
> functions should be designed to be generic enough, so as they could be
> reused for more tests than the ones we'd look at here.
I considered the worker_spi.c module, which demonstrates various SPI 
usage patterns. It might be more beneficial to use this instead of 
creating another test module, isn't it?

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Add support for specifying tables in pg_createsubscriber.
Next
From: Bertrand Drouvot
Date:
Subject: Re: Improve LWLock tranche name visibility across backends