Re: ON ERROR triggers

> The point is to collect comprehensive error reports, mainly about
> failed modifications of complex structured data which is
> created/modified concurrently by several workers in an optimistic
> locking fashion. Because the data is so complex it won't help anybody
> if you print out a message as "index xy violated by tuple ab". Hence I
> want to collect all the errors to give the application/the user the
> possibility to make an overall assessment about what has to be done to
> avoid the error.
...
> > How about savepoints?
>
> This would be my question to you: How about savepoints ?
> Do they help to achieve what I want to achieve ?

Ok, thanks. Yes, savepoints would not allow you to get comprehensive
error reports in all cases (when you need to insert record with duplicate
key to avoid errors caused by absence of such record etc).
Though savepoints allow application to fix an error immediately after this
error encountered (without wasting time/resources) I will not argue with
you about how much such comprehensive reports are useful.

I'd rather ask another question -:) How about constraints in DEFERRED mode?
Looks like deferred mode allows you to do everything you need - ie make ALL
required changes and then check everything when mode changed to immediate.
Also note that this would be more flexible then trigger approach - you can
change mode of individual constraint.

Two glitches though:
1. I believe that currently transaction will be aborted on first error
encountered, without checking all other changes for constraint
violations.
I suppose this can be easily changed for your needs. And user would just
point out what behaviour is required.
2. Not sure about CHECK constraints but Uniq/PrimaryKey ones are not
deferrable currently -:( And this is muuuuuch worse drawback then absence
of comprehensive reports. It's more complex thing to do than on error
triggers but someday it will be implemented because of this is "must
have"
kind of things.

Vadim