Well, I'm all for being logical in my requests and highly structured code. Unfortunately I can't used stored procedures as maybe fifty percent of the databases out there implement them. As to your other solution, I really like the idea of using data functions to map from perl to sql. Unfortunately it looks like using your examples would give me the worst of both worlds, as I would still end up with sql being strewn around in the middle of my code and I see no easy way to easily be "database agnostic" with those subs, other then just writing one set of subs for every single database I want to use.
I suppose in the end I'm probably going to have to do something similar, with different modules containing functions for each different database, but the idea of having large numbers of subroutines that would essentially be exactly the same, for example, postgre subs and mysql subs would probably use almost the exact same sql and so forth, but I couldn't just use the same subroutines because of the one sub where I have to use different sql for whatever reason.
I suppose that writing individual classes for each database and combining it with some sort of factory method would be the simplest way to handle it, perhaps something like:
my $db_type = defined $use_mysql?'mysql':'postgre'; # really simplifie
+d
my $user = new User($db_type);
$user->name;
$user->date;
$user->stuff;