On 2/27/07, Jacques Caron <[EMAIL PROTECTED]> wrote:
Hi,
I would like to submit the following patch for inclusion in the next
release of DBD::Pg:
http://staff.oxado.com/~jc/patch.dbd-pg.async+cancel
This pretty much trivial patch adds 5 new methods:
$sth->pg_sendquery is equivalent to $sth->execute, but only sends the
request, and does not wait for the results
$sth->pg_getresult handles the results
$dbh->pg_busy tells if $sth->getresult will block
$dbh->pg_consume handles incoming data from the server
$dbh->pg_cancel cancels the existing query
pg_sendquery and pg_getresult are really just a split of the existing
execute method, using PQsendQuery* calls then PQgetResult rather than
the original PQexec* calls. The original execute function now just
successively calls both methods (it avoids a lot of code
duplication). Apparently the PQsenqQuery* functions have been there
for quite a while so I believe it should work in all cases, but if
they don't leaving the execute function untouched is always an option.
I have tested a few simple scenarios, but haven't tried it in
production yet, so I can't vouch for the validity of the code, but
the changes are quite minimal and straightforward so I don't expect
much complication.
Any comments welcome.
I like the idea of natively supporting async queries. If it's done
right, at a much higher level this could allow for things like easier
nonblocking POE<->DBI integration. Rather than having ->pg_* custom
interfaces though, I'd really like to see someone spec up a good
generic interface for async queries for DBI itself, and then have Pg
implement them (should take a gander at a few other DBs and see what
their native async interfaces look like, to help formulate what the
generic API should look like). Also, it would be nice if there were a
way to get async notification via a selectable filehandle or something
of that nature, instead of having to periodically check the busy
status.
-- Brandon
