If the subquery emulation has been deprecated, change the short tagline in the NAME section ("Easy-to-use...") to reflect only the primary purposes.

You're right. It has already been removed, even :) I used to be proud of this feature, because it enabled users of MySQL to use subqueries and a lot of people seemed to really want that. But MySQL now supports that natively and thus of course in a much better way. And I don't want to maintain the ugly code needed for it just for database drivers that aren't used much anyway.

The method named _die is confusing, since it doesn't have anything to do with the core die(); perhaps naming it something like done, finished, or destroy would make it clearer that this is a pre-destruction cleanup method

Or during-destruction, or triggering-destruction. It's kind of hard to explain and at the time I really had trouble finding a good name. I still find that hard. Nothing describes it really well. I think _die is as bad a name as the other suggestions. For method names, I never really care about clashing with builtins.

While I think the "keep_statements" functionality is nicely implemented, if its purpose is just for performance, might you be better off using the DBI's built-in prepare_cached instead?

prepare_cached Is dangerous, as described in the documentation of DBI under the "Caveat Emptor" paragraph. Since DBI 1.40, there's a way to make it safe, but I use DBIx::Simple on boxes that have older versions of DBI. Its functionality is also driver dependent.

Another thing is that DBI doesn't limit the number of cached handles, which can be a serious problem in persistent environments like mod_perl.

Oh, and I need to control what happens to STHs because of the extensive error reporting. DBI could give the STH to something that isn't DBIx::Simple. (Which by the way is also a security implication, since you can use it without re-execute()ing. (Of course, nothing realli is safe in Perl, since even lexicals can be accessed from elsewhere...))

In addition to referring people to DBIx::Abstract, you might want to also mention SQL::Abstract, perhaps even with a short example showing how easy it is to use SQL::Abstract with your module.

Good idea. Will do! (By the way - the link in your post is broken)

Update: In fact, the more I think about it, SQL::Abstract is VERY compatible with DBIx::Simple: its return values can be used directly, without modification, with DBIx::Simple's query method. Although I don't like abstracting SQL (unless completely, that is: with Class::DBI), it's the most often requested feature. I could even wrap its four main methods entirely, as none of its methods clash with DBIx::Simple's methods.

That would probably something like: (untested)

sub abstract : lvalue { shift->{abstract} }

for my $method (qw/select insert update delete/) {
    *$method = sub {
        require SQL::Abstract;
        my $self = shift;
        $self->{abstract} ||= SQL::Abstract->new;
        return $self->query($self->{abstract}->$method(@_));
    }
}
[download]

Is there any reason I should or should not do this?

Another update: It's implemented in my local copy now, in an even simpler way. Just to make sure some things, I've emailed the author of SQL::Abstract with some questions, but I don't expect anything negative back. So probably DBIx::Simple 1.23 will have these four new methods.

With regard to testing, I've struggled with the same issue; this kind of testing is trickier than for self-contained modules that don't have to talk to a database. My suggestion would be to use EU::MM's prompt() function to ask the user for a test DSN when Makefile.PL is run; note that EU::MM will skip this automatically when running from within CPAN.

Someone else is working on the tests. I don't know what it'll look like :)