module making calling procedures in DBI easier

I have been working with DBD::Oracle, DBD::mysql and DBD::DB2 in a 
project recently before we decided to settle on Oracle. In the process I 
have developed some code which makes calling procedures and functions in 
a DBD-independent way easier. As we dropped MySQL and DB2 in favour of 
Oracle some of the MySQL and DB2 code is not up to date but I could 
perhaps sort that out. I am tentatively considering releasing this as a 
module on CPAN because a) this sometimes crops up on dbi-users and b) I 
think it may be of general use. My question is where would this sit 
namespace-wise?

The existing code is not a DBIx (mostly because I never found out a 
decent way of chaining DBIx modules and we use DBIx::Log4perl), it is 
just a module which takes a DBI connection handle and simplifies calling 
procedures/functions by a) hiding differences between MySQL, DB2 and 
Oracle b) avoiding having to bind parameters, c) lob handling d) 
mimicing handling output bound parameters even though mysql does not 
have them.

e.g.,

callProc(\%attributes, $schema_or_package_synonym, $proc_fn_name, 
@parameters);

callProc automatically binds the parameters in @parameters in order. If 
they are a simple scalar they are input parameters. If they are a simple 
scalar reference they are an input/output parameter with no specific 
binding type. If they are a reference to a hash then you can use keys of 
blob/clob/cursor to signify how they should be bound and similarly if 
the value is a scalar they are input or scalar reference an input.output 
type. It does not support names parameters as they are not universally 
supported across DBDs - it uses ? or :pN depending on the database.

The said code also has a better (workable) implementation of 
lastInsertId (the one in most DBDs does not work reliably) and an 
interface for sequences but this is of less use and I'd probably leave 
it out.

I could provide more details but I thought I'd sound you out first. I'd 
appreciate any comments even if they are I doubt anyone would use this.

Martin