Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Wed, Jan 27, 2016 at 10:18 PM, David G. Johnston wrote: > Prepare creates a plan and a plan has a known output structure. What you > want is an ability to give a name to a parsed but unplanned query. This is > not something that prepare should do as it is not a

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Thu, Jan 28, 2016 at 7:48 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Robert>Hmm, so in your example, you actually want replanning to be able to > Robert>change the cached plan's result type? > > I want backend to cache _several_ plans behind a single "statement name". > I

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

Robert>Hmm, so in your example, you actually want replanning to be able to Robert>change the cached plan's result type? I want backend to cache _several_ plans behind a single "statement name". I want to treat "prepare...exec...deallocate" dance as an optimization step for a simple

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Monday, January 25, 2016, Vladimir Sitnikov wrote: > I want to treat 'prepare' operation as an optimization step, so it is > functionally equivalent to sending a query text. > > In other words, I would like backend to track search_path and other > parameters if

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Mon, Jan 25, 2016 at 2:11 PM, Vladimir Sitnikov wrote: > I want to treat 'prepare' operation as an optimization step, so it is > functionally equivalent to sending a query text. > > In other words, I would like backend to track search_path and other > parameters

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

I want to treat 'prepare' operation as an optimization step, so it is functionally equivalent to sending a query text. In other words, I would like backend to track search_path and other parameters if necessary transparently‎, creating (caching) different execution plans if different plans are

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Mon, Jan 25, 2016 at 12:47 PM, Andres Freund wrote: > On 2016-01-25 12:39:29 -0500, Robert Haas wrote: >> What is the ideal behavior, in your view? > > FWIW, I think that for a lot of practical cases the previous behaviour, > where a prepared statement was defined in the

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Thu, Jan 21, 2016 at 3:55 PM, Vladimir Sitnikov wrote: > Robert>Are you really seeing the same behavior in all versions? > > I do not have "pre 9.1" at hand, however all 9.1, 9.2, 9.3, 9.4, and > 9.5 are affected. > > 9.1 just silently executes "old statement" as

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

Andres Freund writes: > On 2016-01-25 12:39:29 -0500, Robert Haas wrote: >> What is the ideal behavior, in your view? > FWIW, I think that for a lot of practical cases the previous behaviour, > where a prepared statement was defined in the context of the search path > set

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On 2016-01-25 12:39:29 -0500, Robert Haas wrote: > What is the ideal behavior, in your view? FWIW, I think that for a lot of practical cases the previous behaviour, where a prepared statement was defined in the context of the search path set during the PREPARE, made a lot more sense. The current

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

On Wed, Jan 20, 2016 at 10:23 AM, Vladimir Sitnikov wrote: >> I believe, and the conclusion was that >>if you think you need this, you're doing it wrong > > So what is the recommended approach to use server-prepared statements > at the client side (I mean at JDBC

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

Robert>Are you really seeing the same behavior in all versions? I do not have "pre 9.1" at hand, however all 9.1, 9.2, 9.3, 9.4, and 9.5 are affected. 9.1 just silently executes "old statement" as if search_path was not modified at all. 9.2, 9.3, 9.4, and 9.5 all fail with "cached plan must not

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

> I believe, and the conclusion was that >if you think you need this, you're doing it wrong So what is the recommended approach to use server-prepared statements at the client side (I mean at JDBC driver side)? Currently "prepare, switch search_path, execute" leads to "cached plan must not

[HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

Hi, There's a not so well known issue of "set search_path" and "server-prepared statement" usage. In short, it does not always work. See more details in [1]. There issue has reproduced once again recently (see [2], that explains that search_path is modified for a multi-tenant setup). Even

Re: [HACKERS] Set search_path + server-prepared statements = cached plan must not change result type

Vladimir Sitnikov writes: > Here's my question: why change in search_path does NOT generate > ParameterStatus message from the backend? The protocol specification includes a list of the small number of GUCs for which ParameterStatus messages are generated, and that