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 natural extension of its
> pres
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 wan
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 "exec...exec...
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 necessary transparently, creati
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 if necessary transparently, c
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
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 during the PREPARE, made
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 context of the search p
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
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 if search_path was not
> modifi
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 c
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 driver side)?
>
> Currently "prep
> 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 chang
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 is not one
of them.
This has b
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 though
15 matches
Mail list logo