> > PostgreSQL has recently added a true server-side prepare, which > raises some issues in regards to the prepare/execute DBI model. > Our initial thought was simply to use the new prepare/execute > when it was available on the backend, and keep everything > transparent to the user. However, there are cases where a > local (or non server-prepared) prepare is preferred, so we need > to allow both. One idea I had, which Rudy Lippan also thought > of for DBD::mysql, is to have a global and a local flag to toggle > between the two. The global can be set at connect and resides > at the $dbh level. The local is an extra attrib send to the > prepare() method, which would override the global method. Toggling > between the two *after* the prepare would even be possible, > especially if you have an intelligent app that realizes that > it may need to mix and match them. > > Has anyone else run into this? Does the above sound like a good > solution? (The 'local' prepare for DBD::Pg just means that we > build the complete SQL statement ourselves and send that off > to the server). > > - -- > Greg Sabino Mullane [EMAIL PROTECTED]
Not certain about your needs for client side prepare, but I've a similar issue with Teradata, but solely for performance purposes. In essence, there are lots of operations for which prepare doesn't provide much except a "pass/fail" syntax check (INSERT, UPDATE, DELETE, various DDL), which will get handled at execute time anyway. Performing these PREPARE operations on a multiTerabyte DBMS with quite probably 1000's of concurrent users is probably not a good idea. So I trap those queries in the driver, do a simple syntax check, and dummy up the statement metadata (usually, none). However, there are times where a full prepare of these items is needed (e.g., during script compile in my IDE, TeraForge). In that case, I've provided a 'tdat_compatibility' attribute that specifies a maximum compatibility level of the DBD version that the app expects. This has the advantage that it can be applied not only to this particular issue, but to other behaviors as well. HTH, Dean Arnold Presicient Corp. www.presicient.com
