ON ERROR triggers

From: Holger Krug <hkrug(at)rationalizer(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: ON ERROR triggers
Date: 2002-01-04 16:36:57
Message-ID: 20020104173657.A24700@dev12.rationalizer.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

For an application I have to code I currently implement ON ERROR
TRIGGERS which shall be called after UNIQUE, CHECK, NOT NULL and REFERENCES
violations.

The implementation plan is as follows:

1) Make `CurrentTransactionState' static in `xact.c' (done, could
be posted for 7.2, because this could be seen as a bug)
2) Allow a transaction to be marked for rollback, in which case
it proceeds but rolls back at commit time. It is not possible
to remove the mark, hence database integrity is assured. (done)
3) Add an ON ERROR UNIQUE trigger OID to pg_index. If the uniqueness
constraint is violated and such a trigger exists, the transaction is
marked for rollback (but not actually rolled back) and the error
trigger is called (getting the conflicting tuple as OLD and the
tuple to be inserted as NEW). (what I'm currently doing)
4) Add ON ERROR CHECK, ON ERROR NOT NULL and ON ERROR REFERENCES triggers
in a similar way. (to do)

This supersedes what I discussed some days ago with Tom Lane on this list.

My questions are:

A) Are the hackers interested to integrate those changes, if reasonable
coded, into the PostgreSQL sources, e.g. for 7.3 ?
B) What are the hackers' proposals for the syntax at the query string level.
I think about something like:
UNIQUE [ ON ERROR trigger ( arguments ) ]
CHECK ( expression ) [ ON ERROR trigger ( arguments ) ]
NOT NULL [ ON ERROR trigger ( arguments ) ]
REFERENCES reftable [ ( refcolumn [, ... ] ) ]
[ MATCH FULL | MATCH PARTIAL ] [ ON DELETE action ] [ ON UPDATE action ]
[ ON ERROR trigger ( arguments ) ]
C) Most of the existing triggers would become error-prone, because the
checks made at trigger start do not comprise the new possibilities to
call a trigger as error handler. Hence if a trigger, which is
conceived to be a e.g. BEFORE INSERT trigger is used as a e.g.
ON ERROR CHECK trigger, it would not get informed about this. The
results would be unpredictable.
Is this seen to be a problem ?
Don't forget: Nobody is forced to use a BEFORE INSERT trigger as a
ON ERROR CHECK trigger.

Good luck for 7.2 !

--
Holger Krug
hkrug(at)rationalizer(dot)com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Holger Krug 2002-01-04 16:42:14 Re: sig 11 in RC3
Previous Message Tom Lane 2002-01-04 16:02:04 Re: sig 11 in RC3