Re: Prepared statements considered harmful - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Prepared statements considered harmful
Date
Msg-id 44F72780.5020001@dunslane.net
Whole thread Raw
In response to Re: Prepared statements considered harmful  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Prepared statements considered harmful  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout wrote:
> On Thu, Aug 31, 2006 at 06:43:38PM +0100, Gregory Stark wrote:
>   
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>     
>>> - Redefine "prepared" to mean "parsed" rather than "parsed and planned".
>>>       
>> Then you would be going very much against the user's expectations. 
>>
>> Driver interfaces expose very clearly to the user an explicit interface to
>> prepare and execute a query separately. What your proposing is to go behind
>> the user's back and do what he's gone out of his way to tell you not to do.
>> You can always choose to prepare your queries immediately before use. Most
>> drivers even supply an interface to do so in a single step for convenience.
>>     
>
> Is that really so? Under Perl DBI, the only way to get a statement
> handle is to "prepare" it. Yet I don't want to use server-side prepares
> because I know of the problems it causes. The "single-step" approach
> provides no statement handle at all, which has several drawbacks.
>
> People are encouraged to use prepared stataments for clarity and
> security reasons, not speed. I would really like an option to choose
> between:
>
> - slightly more planning time but always good plans
> - plan once and be unforgiving if the plan doesn't work with the
> parameters
>
> I'd take the first option anyday, but that's just the types of queries
> I'm doing.
>
> Have a nice day,
>   

According to the docs you can actually choose between server side 
prepare or not on a per call basis. It contains this example:
            $sth->{pg_server_prepare} = 1;            $sth->execute(22);            $sth->{pg_server_prepare} = 0;
     $sth->execute(44);            $sth->{pg_server_prepare} = 1;            $sth->execute(66);
 

cheers

andrew


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Second try committing the path
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Interval aggregate regression failure