Re: Avoiding bad prepared-statement plans.

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 SQL command text.

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