Re: Poor plan choice in prepared statement

On Tue, Dec 30, 2008 at 1:09 PM, Scott Carey <scott(at)richrelevance(dot)com> wrote:
> There is no way to force Postgres to re-plan a prepared statement. In many cases, this would be a hugely beneficial feature (perhaps part of the definition of the statement?).
>
> I have had similar issues, and had to code the application to prevent SQL injection (Postgres $ quotes and other stuff is helpful, but not always adequate or easy). With the current state of things, you'll have to often do your SQL injection defense in your application due to this weakness in prepared statements.
>
> I have also had a case where one query would take a couple hundred ms to parse, but was fairly fast to plan and execute (1/3 the parse cost) -- yet another case where a prepared statement that re-plans each execution would be helpful. At least you can prevent SQL injection and cut the parse cost. Its not all about the cost of planning the query.
>

Can you point out any standard ways of preventing sql injection
(within or without php)? I would really rather not have to roll my own
input sanitation code if there are standard methods available.
For example, addslashes is apparently not recommended (according to a
warning in the postgresql docs at
http://wiki.postgresql.org/wiki/8.1.4_et._al._Security_Release_FAQ).

Thanks!

Bricklen