Re: Let plan_cache_mode to be a little less strict
От | Michael Paquier |
---|---|
Тема | Re: Let plan_cache_mode to be a little less strict |
Дата | |
Msg-id | aIv0gh4prVrGAIjT@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Let plan_cache_mode to be a little less strict (Sami Imseih <samimseih@gmail.com>) |
Ответы |
Re: Let plan_cache_mode to be a little less strict
|
Список | pgsql-hackers |
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. 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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: