On Tue, May 29, 2012 at 9:20 PM, John M. Gamble <jgam...@ripco.com> wrote: > On Tue, May 29, 2012 7:46 am, Matthew Musgrove wrote: >> Joel, >> Perhaps you could explain how DBIx::Pg::CallFunction differs from >> DBIx::ProcedureCall and why someone would choose one over the other? >> >> http://search.cpan.org/dist/DBIx-ProcedureCall/ProcedureCall.pm
DBIx::Pg::CallFunction works only for functions with named parameters (=named input arguments). I consider this a feature, as it requires the developer to use named parameters for all functions, which is much safer than relying on the order of arguments. This is especially important in a Perl->PostgreSQL bridge as Perl is more or less untyped while PostgreSQL is strictly typed. DBIx::ProcedureCall does not work with named parameters. It also seems very outdated, as it claims in the manual "PostgreSQL stored procedures do not support OUT parameters.", which is not true. I also don't like that it exports functions and that you have to explicitly specify which functions to use in the source code. In my case, this will be totally dynamic, the Perl application will have no clue of what functions the user might want to use, that's why I use AUTOLOAD. I guess one could try to merge the two projects, but it's too much work for me, and I only need this for PostgreSQL. I think it makes sense to allow a PostgreSQL-only module because of the much simpler implementation possible thanks to not trying to support any database. The entire code is only ~100 lines and super-simple. This code is simply too important for me to risk using anything more complex than that, when it's not necessary. >From >http://cpansearch.perl.org/src/THILO/DBIx-ProcedureCall-0.11/ProcedureCall/PostgreSQL.pm: # if there is one more arg and it is a hashref , then we use with named parameters if (@_ == 1 and ref $_[0] eq 'HASH') { die "PostgreSQL does not support named parameters, use positional parameters in your call to '$name'. \n"; } # otherwise they are positional parameters > > Could it be that one is calling built-in functions, while the other is > calling stored procedures? It's hard to tell from the documentation > though. Joel, could you expand on that please? It works with any [functions/stored procedures] with named parameters. Most built-in postgres functions have no named arguments, such as round(numeric), sqrt(numeric), etc. These cannot be accessed using my module, and I cannot see why one would need to use them from Perl. If you need them, simply make your own wrapper function with named parameters and you can use my module. > > -john > > >
