Re: [SQL] 16 parameter limit

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: John Proctor <jproctor(at)prium(dot)net>
Cc: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, josh(at)agliodbs(dot)com, peter_e(at)gmx(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-patches(at)postgresql(dot)org
Subject: Re: [SQL] 16 parameter limit
Date: 2002-08-14 02:43:18
Message-ID: 200208140243.g7E2hI323252@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches pgsql-sql


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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-08-14 02:47:06 Re: Inheritance
Previous Message Hannu Krosing 2002-08-14 02:42:49 Re: Open 7.3 items

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 02:48:12 Re: [SQL] 16 parameter limit
Previous Message Neil Conway 2002-08-14 02:29:05 updated lock listing patch

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 02:48:12 Re: [SQL] 16 parameter limit
Previous Message Wei Weng 2002-08-13 20:39:24 concurrent connections is worse than serialization?