While I can certianly see this as a potential growth of a desire to explore a tied scalar, as an interface, it sucks.

Here is, perhaps, a better API. Tied filehandles are, indeed, the way I'd go. For reading:

tie $dbfh, 'Tie::DBI', $dsn, $user, $pass, 'id, name from foo';
while (my $record = <$dbfh>) {
 print "ID:   ", $record->{id}, "\n";
 print "Name: ", $record->{name}, "\n";
}
[download]

For writing:

# $dbfh continues from above
$dbfh->print(join $/, (id => '42', name => 'Answer', '');
[download]

The rule for reading is that each "line" is a record, as a hash-ref. The rule for writing is that you should give the row hash, flattened to a string by joining it with $/ (normaly newline), with an extra newline meaning "done with this record". Printing hashrefs (or arrayrefs, at the user's option) would be nicer, but I don't think you can do that with the tied FH interface.

Really, I don't see all that much use for the "write" interface, but the "read" interface seems interesting to me -- there's a lot of idioms around file-processing that don't translate 1:1 to table processing for no good reason.

In fact, now that I think about it more, it might be more interesting to have the tied FH behave exactly like a CSV file.

my $dbfh = tie $dbfh, 'Tie::DBI', $dsn, $user, $pass, 'id, name from f
+oo'; # Support optional prameters to give the defintion of comma, new
+line, etc?  Take ideas from CSV_XS
while (<$dbfh>) {
  chomp;
  my ($id, $name) = split /,/, $_;
  print "$id: $name\n";
}

print $dbfh (qq(42, "Answer"\n));
# Note that the \n isn't optional; you should wait for it, putting inp
+ut in an interal buffer until you see it, then flush the whole line. 
+ Support some special syntax to specifiy a NULL, or to leave it out a
+nd let an AUTONUMBER column do it's thing?
[download]