From: Karl O. P. <ko...@me...> - 2012-10-01 01:36:05
|
Hi, So, after long pursuing what now seem the wrong path, if ppa is to take multiple sql statements from the user's entry on the free-form sql page and supply the user with results from all the statements the way forward now seems clear. (For me this has been the holy grail, to have ppa be interactive in the same way that psql is.) The libpq functions PQsendQuery() and PQgetResult() put the burden of distinguishing one sql statement from another on libpq. These functions are in php, but not in adodb or pdo. http://www.postgresql.org/docs/9.2/static/libpq-async.html It seems clear that we want to avoid having write and maintain an SQL statement parser in ppa if at all possible. Since libpq supplies a parser I think that if we want this feature we need to use what libpq supplies. I don't see this feature getting into either adodb or even pdo any time soon, if ever, since they are supposed to be cross-database abstractions, other databases in so far as I am aware do not have this feature, and neither adodb nor pdo is likely to implement a parser in order to supply the feature across all databases. As I see it there are only 2 possible approaches: hack the functionality into adodb and maintain that patch forever. or use the postgres functions built into php, including PQsendQuery() and PQgetResult(), when processing user supplied sql. Although postgres will not then be abstracted away in the user-supplied query processing code, and will be different from the rest of the code, I don't see this as a huge obstacle for reasons that I'd be happy to go into. So, my inclination is to go ahead and implement the ability to process multiple user-supplied sql statements using php's postgres db functions. But I want some consensus before I get started, this time. :-) I'd like to discuss all options. Can this be on the table? How should we proceed, email, irc, or ??? Thanks, Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |