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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Sun, 13 Apr 2008, Ivan Sergio Borgonovo wrote:

> On Sun, 13 Apr 2008 16:02:35 +0800
> Craig Ringer <craig@postnewspapers.com.au> wrote:
>
> > > I think this logic is already somewhere in the driver or the pg
> > > engine. Whatever you write at the application level a) risk to be
> > > a duplication of part of the parser b) risk to be less smart than
> > > the parser itself and let slip something.
>
> > ... in which case it sounds like you need to extend the Pg DB
> > interface to do what you want. It might be worth hacking together a
> > proof of concept and posting it to -hackers and the PHP interface
> > maintainers, along with a rationale for its inclusion.
>
> I wish I'd be so familiar with pg C code.
> And it looks as if such a thing won't be that welcome.

Well, Tom suggested making the PHP interface optionally use PQexecParams
rather than PQexec even when using a full query string with no parameters
as that interface doesn't support multiple queries, so I don't think it's
necessarily entirely unwelcome - of course, we're not the PHP team, so
they might view it differently.

One issue is that it appears that PHP's interface tries to support cases
where the libpq version doesn't have PQexecParams, and you'd probably be
best to follow the existing style, only using PQexecParams if
HAVE_PQEXECPARAMS and the configuration option is set.

There appear to be 15 calls to PQexec inside the PHP ext/pgsql.c for the
version I have of PHP. 7 of them appear to use a constant string in the
call, so don't necessarily need to change. A few of the others are
generated single queries for metadata and the like and probably don't need
to be configurable to allow multiple queries but merely on
HAVE_PQEXECPARAMS.


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general