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
> >
> >
> >
>

Reply via email to