I am a little confused here. I agree that there are points mentioned here
that need work, but correct me if I am wrong....
> On Friday 09 January 2004 14:48, Bob.Henkel@hartfordlife.com wrote:
<snip>
> > 1. Need commit roll back in pl/pgsql much like Oracle does
> > 2. Need exception handling in pl/pgsql must like Oracle does
> > 3. A>Need sub transactions . B>And if an inner transactions fails it
> > should not cause all others to fail. If #2 was robust enough than #3 B
> > might not be an issue.
OK. I am not sure about Oracle's exception handling and commit rollback, as
my experience there is limited, but the subtransaction issue is being worked
on.
> > 1. It's a must if you have long running complicated and time consuming
> > batch processing. There is no reason why one should say do all of
commit
> > and rollbacks from the client.
What is described here is a scenario where a stored proceedure wraps several
transactions. This is a feature many people have asked for and it is in the
Todo list, but so far there is no word on any ETA. Tom Lane has described
it as a complicated problem.
> > 2. Without this you can't trust complicated code as far as I'm
concerned.
> I
> > need to log some errors and continue processing and for others log and
> exit
> > which I think you can do now in pl/pgsql. Point being pl/pgsql
exception
> > handling is almost nonexistent at best.
> >
Hmmm.... Here is where you have lost me. Can anyone tell me why RAISE
WARNING doesn't work for the errors that need to continue and RAISE
EXCEPTION doesn't work for the errors that need termination. Also, if you
need customized logging, you could always use pl/perlu for to create a more
complex logging system that doesn't log to the same PostgreSQL log. If the
results are written to an outside file, they would be logged independent of
whether the transaction was committed or rolled back. This would be trivial
to impliment if the requirements weren't large.
Best Wishes,
Chris Travers
