On Sun, 13 Apr 2008, Ivan Sergio Borgonovo wrote: > On Sun, 13 Apr 2008 16:02:35 +0800 > Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> 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.
