On Sep 29, 2009, at 2:51 PM, Darren Duncan wrote:
Going the other way, in SQL, there is a single terse SQL statement for starting/ending transactions, and doing the thing with savepoints. So for aside from maybe some consistency with legacy DBI features, why should DBI objects have begin/commit/rollback or methods specific to start/end savepoints at all? Why doesn't the user just do it in SQL like they do everything else in SQL? Its not like DBI is abstracting away other SQL language details, so why should it do so with the transaction/savepoint managing SQL? Unless some DBMSs support transactions but not with SQL? So maybe changing nothing in DBI is actually the best approach concerning savepoints.
We already have the example of DBI transaction support; savepoints are just an extension of that. And if different databases support different syntaxes, it'd be nice to have that abstracted into drivers.
For example, MySQL has the RELEASE SAVEPOINT syntax, but it does not exist in Oracle, where the releasing of savepoints is automatic. It's best to have an abstract DBI interface for things like that, IMHO. Yeah, I know that the DBI doesn't cover everything in the SQL standard in this way; nor would I want it to. But as I said, the example of savepoints follows along from the transaction stuff almost identically.
Best, David
