Joel, This is exactly what I looking for. I should have read the PostgreSQL specific docs for DBIx::ProcedureCall because I have only used it from Oracle. From what you have written here, I will want to use DBIx::Pg::CallFunction when finally get us ported from Oracle to PostgreSQL.
Matt On Tue, May 29, 2012 at 10:04 AM, Joel Jacobson <j...@trustly.com> wrote: > 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 > > > > > > >