From: Bruce Momjian <pgman@candle.pha.pa.us>
To: John Proctor <jproctor@prium.net>
Cc: Neil Conway <nconway@klamath.dyndns.org>
Cc: josh@agliodbs.com
Cc: peter_e@gmx.net
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-patches@postgresql.org
Subject: Re: [SQL] 16 parameter limit
Date: Tue, 13 Aug 2002 22:43:18 -0400 (EDT)
Message-ID: <200208140243.g7E2hI323252@candle.pha.pa.us> (raw)
In-Reply-To: <200204170619.g3H6JKa29940@slxmail01.prium.net>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pgman@candle.pha.pa.us, jproctor@prium.net, nconway@klamath.dyndns.org, josh@agliodbs.com, peter_e@gmx.net, tgl@sss.pgh.pa.us, pgsql-patches@postgresql.org
Subject: Re: [SQL] 16 parameter limit
In-Reply-To: <200208140243.g7E2hI323252@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox