The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

NAME

Changes - List of significant changes to DBIx::Pg::CallFunction

Changes in 0.010 Updated Documentation.

Changes in 0.009 Updated Documentation.

Changes in 0.008 Updated Documentation and made the call method private, renamed to _call.

Changes in 0.007 Changed pg_proc_jsonrpcd into a plain PSGI App to let for e.g. Apache2, mod_perl and Plack::Handler::Apache2 handle the server task. Added how-to on how to setup pg_proc_jsonrpc.psgi.

Changes in 0.006 Optimized _proretset SQL query Makefile.PL format changed to Module::Install Add script pg_proc_jsonrpc, starting a JSON-RPC daemon

Changes in 0.005

  Added Plack PSGI example on how to create a JSON-RPC server,
  exposing the PostgreSQL database as a JSON-RPC service.
  Added support for functions with no arguments.

Changes in 0.004

  Added test-case to check if error is thrown when multiple functions
  matches.
  Moved entire proretset check to SQL. Before the SQL only selected
    candidate functions matching the arguments, while Perl filtered
    out the OUT arguments and compared the arguments. Now it is all
    done using SQL only.
  Updated documentation, mention DBIx::ProcedureCall under SEE ALSO.

Changes in 0.003

  No changes, but had to change version number to upload to PAUSE,
    as you cannot upload the same file twice.

Changes in 0.002

  Changed license to MIT
  Various indentation and regex fixes
  Added description of the pg_catalog.pg_proc.proretset column
  Make sure we get the proretset value for the right function,
    the WHERE statement could possibly match other functions
    sharing the only part of the arguments, as some of the
    arguments could be OUT arguments. This is now fixed
    by comparing only the IN arguments.
    If two functions matches exactly the same IN argument
    names, an error is thrown.
    Thus, overloading of functions with the same argument
    names is not possible. Would be possible to implement,
    but that would make the interface more cumbersome,
    as you would need to specify the data types of all
    input arguments. Perhaps this could be added as an
    optional third argument to the call() function.
    I don't need this now, so I'll put it on the TODO
    until someone needs it and complains. Better to keep it
    simple for now.

Changes in 0.001

  First version.