Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id m2hbp1ydrh.fsf@hi-media.com
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Avoiding bad prepared-statement plans.
List pgsql-hackers
Craig Ringer <craig@postnewspapers.com.au> writes:
> 1) People preparing statements to save on parse+plan time; and
> 2) People preparing statements to get convenenient param placement.
>
> I suspect that most of (1) also want (2), but many of (2) don't care much
> about (1) and are just preparing statements for sql-injection safety (param
> placement), because they've been told to by someone, because their library
> does it for them, etc.
>
> So: Would it be easier to handle control of replan vs no-replan at PREPARE
> time? Or would that have very much the same protocol/pl change issues?
 http://www.postgresql.org/docs/8.4/static/libpq-exec.html#LIBPQ-EXEC-MAIN
 PQexecParams
  Submits a command to the server and waits for the result, with the  ability to pass parameters separately from the
SQLcommand text.
 

So I think what you're talking about is already in there.
-- 
dim


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Avoiding bad prepared-statement plans.
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: Anyone know if Alvaro is OK?