On Tue, Dec 30, 2008 at 1:09 PM, Scott Carey <sc...@richrelevance.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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
