Re: Let plan_cache_mode to be a little less strict

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Let plan_cache_mode to be a little less strict
Date: 2025-08-01 13:07:08
Message-ID: ee429d41-2ea3-43ce-bde9-70475ab4df9c@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-08-01 13:11:15 Re: Improve LWLock tranche name visibility across backends
Previous Message Andrew Dunstan 2025-08-01 12:56:07 Re: Add support for specifying tables in pg_createsubscriber.