Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Holger KrugDate: 2002-01-04 16:42:14
Subject: Re: sig 11 in RC3
Previous:From: Tom LaneDate: 2002-01-04 16:02:04
Subject: Re: sig 11 in RC3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group