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.
