On Sun, 13 Apr 2008 11:49:58 +0200 Martijn van Oosterhout <kleptog@xxxxxxxxx> wrote: > On Sun, Apr 13, 2008 at 10:37:52AM +0200, Ivan Sergio Borgonovo > wrote: > > > Because you appear to be seeking something to protect against > > > programmers who do not follow coding guidelines, and that should > > > help even if code review processes fail to catch the problem. > > > Were that not the case you'd be able to use some of the other > > > suggestions made here. I quote: > > > > Default 1 statement, switch to more than one have to be > > "voluntary" and "conscious" and can be easily spotted with grep > > only. > > It's not quite so simple, there are backward compatability issues. I'm aware of the problem. I couldn't use legacy as an argument just to break other legacy stuff ;) Actually I pointed out that giving no option is a bad idea, and that's what mysql driver do, if I remember correctly. I'd say default at the application level. While it is pretty common to call pg_query directly, places where you use pg_connect are fewer and generally is something less frequently called directly and already wrapped into something that will load connection parameters. You'd switch multiple statement off (but still not at the connection level) when you use pg_connect and if you want multiple statements you'd have to turn it on before you issue a pg_query, and turn it off afterwards. Of course if pg_query is NEVER (or very seldom) called directly in the code... you'd already have a wrapper to turn every pg_query into a pg_prepare + pg_execute sequence. I'm not here to ask anyone will implement my ideas in the postgres driver for php ;) and from what I've learnt on pg_prepare/pg_execute I've enough tools to mitigate the problem at least in MY code since pg_query is NEVER called directly. I thought that _prepare _execute was just a more conscious form of fprint... while it is not. So I kept thinking that it was still possible to inject multiple statements. thanks to everybody who insisted enough to let me grasp what you were writing by a long time. -- Ivan Sergio Borgonovo http://www.webthatworks.it
