Re: [SQL] 16 parameter limit

Added to TODO:

        o Improve PL/PgSQL exception handling
        o Allow PL/PgSQL parameters to be specified by name and type during
          definition
        o Allow PL/PgSQL function parameters to be passed by name,
          get_employee_salary(emp_id => 12345, tax_year => 2001)
        o Add PL/PgSQL packages

>
>
> OK, here goes.
>
> 1) More than 16 parameters. ? This can be parameter configurable if
> necessary, but up to 128 would cover 99.9%.

Done to 32.

>
> 2) Better exception handling. ?The procedure should be able to trap any data
> related exception and decide what to do.   No function should ever abort.  It should raise a trappable exception and
letme decide what to do. 

Added.

>
> 3) Allow transactions inside of functions. ? Mostly for incremental commits.
> Each transaction shoud be implicitely started after any CrUD statement and
> continue until a commit or rollback.

When we have subtransactions, we will be able to do this.

>
> 4) Allow autonomous transactions. ?This is related to number 2. ?In Oracle, I
> can track every single exception and log it in a central table with details,
> even if I rollback the current transaction or savepoint. ? This is a must for
> tracking every single database error in an application at the exact point of
> failure.

Same.

> 5) Find a way to get rid of the requirement to quote the entire proc. ? This
> is very clumsy. ? The PL/pgSQL interpreter should be able to do the quoting
> and escape what it needs.

This is pretty hard, especially because we have plug-in languages.  I
don't see a way to do this.

>
> 6) Allow function parameters to be specified by name and type during the definition. Even aliasing is cumbersome and
errorprone on large procs, especially during development when changes are frequent. 

Added,

>
> 7) Allow function parameters to be passed by name, not just positional. ?i.e.
> get_employee_salary(emp_id => 12345, tax_year => 2001).

Added.

>
> 8) Add packages. ?This is a great way to group related functions, create
> reusable objects, like cursors, etc.

Added.

>
> 9) Allow anonymous PL/pgSQL blocks. ? It should not be required to create a
> function for every PL/pgSQL block. ? Often, I just want to do something quick
> and dirty or write complex blocks that I don't even want saved in the
> database. ?I can just keep then in a file and execute when necessary.

I don't see the point here, except perhaps you want TEMP functions?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073