I came across someone asking about DBIx::ProcedureCall today on Perl Monks in Execute Oracle Stored procedure using DBIx::ProcedureCall. Years ago I remember finding DBIx::ProcedureCall when we were about to embark on writing an application that used stored procedures in DB2, Oracle and MySQL. DBIx::ProcedureCall did not support DB2 and MySQL then and I was not that happy about the way it creates symbols in Perl for database procedures/functions so I dismissed it and I wrote my own code. When I saw it again on Perl Monks I thought I'd take another look at it and was surprised the supported DBDs has not increased (it is still Oracle and Postgres).
We use a lot of Oracle procedures so in particular I liked the way you can call a database function from the command line which returns a reference cursor and output the result-set with a simple:
perl -MDBIx::ProcedureCall::CLI -e function 'mypkg.my_func_returning_cursor:fetch[]'
and it calls mypkg.my_func_returning_cursor, retrieves the output reference cursor then outputs all the rows from it.
Being the maintainer of DBD::ODBC I wondered how much effort it would be to add support for ODBC.
It turns out it is not that hard to add support for another database/DBD to DBIx::ProcedureCall but the method used to decide which code to use for creating the SQL is based on what DBI's get_info(17) which is the database name and not the DBD name. For ODBC this is not good as ODBC supports hundreds of databases (which would require creating hundreds of modules for DBIx::ProcedureCall) but the ODBC syntax for calling a procedure is well defined. I've suggested DBIx::ProcedureCall continues to use get_info(17) but when this fails falls back on the DBD driver name. Ideally, the user of DBIx::ProcedureCall would specify the method used as just because the database is Oracle does not mean you are using DBD::Oracle - you could be using DBD::ODBC.
Anyway, I've submitted the changes to Add support for DBD::ODBC and await to see what happens.