Eaglet,
In the future, please refrain from cross-posting on multiple PostgreSQL
lists. We get enough traffic without seeing the same message on 3
lists.
> The goal to achieve is to trap every kind of execution errors without
> trying
> to prevent their occurrence.
> In any case, I usually can't be sure the function (F_EXT) works
> correcty: an
> exception could be lanched by an internal function (F_INT), I
> couldn't know
> to estabilish what happens and where ...
Unfortunately, PG/plSQL does not currently support any programmed
exception handling. If an exception occurs in a pgplsql function, it
rolls back the entire function, including rolling back any calling
functions on a cascading basis.
This is partly due, as I understand it, to Postgres' lack of support for
nested transactions. Hopefully one of the Core Team will speak up with
the prognosis on fixing this particular issue. Right now, projects
needing sophisticated exception handling are being done in middleware
languages that support it, such as Java and Perl.
See Oracle <--> Postgres porting guides at
http://techdocs.postgresql.org/
-Josh
______AGLIO DATABASE SOLUTIONS___________________________ Josh Berkus Complete
informationtechnology josh@agliodbs.com and data management solutions (415) 565-7293 for law firms, small
businesses fax 621-2533 and non-profit organizations. San Francisco
