On Sun, 13 Apr 2008 11:49:58 +0200
Martijn van Oosterhout <kleptog@svana.org> 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
