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
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 |