From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200208140243.g7E2hI323252@candle.pha.pa.us>
Subject: Re: [SQL] 16 parameter limit
In-Reply-To: <200204170619.g3H6JKa29940@slxmail01.prium.net>
To: John Proctor <jproctor@prium.net>
Date: Tue, 13 Aug 2002 22:43:18 -0400 (EDT)
Cc: Neil Conway <nconway@klamath.dyndns.org>, josh@agliodbs.com,
	peter_e@gmx.net, tgl@sss.pgh.pa.us, pgsql-patches@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII


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 let me 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 error prone 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