Skip site navigation (1) Skip section navigation (2)

Re: Avoiding bad prepared-statement plans.

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>
Cc: "Greg Stark" <gsstark(at)mit(dot)edu>, "Jeroen Vermeulen" <jtv(at)xs4all(dot)nl>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bart Samwel" <bart(at)samwel(dot)tk>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-18 16:47:01
Message-ID: op.u8b0wnhteorkce@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine  
<dfontaine(at)hi-media(dot)com> wrote:

> "Pierre C" <lists(at)peufeu(dot)com> writes:
>> Problem with prepared statements is they're a chore to use in web apps,
>> especially PHP, since after grabbing a connection from the pool, you  
>> don't
>> know if it has prepared plans in it or not.
>
> Have you met preprepare yet?
>
>   http://preprepare.projects.postgresql.org/README.html
>   http://packages.debian.org/source/sid/preprepare
>
> Regards,

Hey, this thing is nice.
How hard would it be to put a hook in pg so that, instead of raising an  
error and cancelling the txn when EXECUTing a statement that is not  
prepared, it would call a user function (of the user's choice) which  
would, if possible, prepare said statement, or if not, raise the error ?

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-02-18 16:54:31
Subject: Re: Avoiding bad prepared-statement plans.
Previous:From: Dimitri FontaineDate: 2010-02-18 15:52:48
Subject: Re: remove contrib/xml2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group