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

Re: truncate in combination with deferred triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: pgsql-bugs(at)postgresql(dot)org, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
Subject: Re: truncate in combination with deferred triggers
Date: 2006-08-21 18:56:54
Message-ID: 5867.1156186614@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Markus Schiltknecht <markus(at)bluegap(dot)ch> writes:
> CREATE TABLE category (
>      id INT PRIMARY KEY,
>      name TEXT);

> CREATE TABLE category_todo (
>      cat_id INT REFERENCES category(id)
>          DEFERRABLE INITIALLY DEFERRED
> );

> BEGIN;

> INSERT INTO category (id, name) VALUES (0, 'test');
> INSERT INTO category_todo (cat_id) VALUES (0);
> TRUNCATE category_todo;

> COMMIT;

> -- COMMIT fails with: 'failed to fetch new tuple for AFTER trigger'

Hm.  At least for this case, it seems the nicest behavior would be for
TRUNCATE to scan the deferred-triggers list and just throw away any
pending trigger firings for the target table(s).  I wonder however
whether there are cases where that would be a bad idea.  It might be
safer for the TRUNCATE to error out if there are any pending triggers.
Stephan, any thoughts about it?

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2006-08-21 20:43:58
Subject: Re: truncate in combination with deferred triggers
Previous:From: Markus SchiltknechtDate: 2006-08-21 18:24:12
Subject: truncate in combination with deferred triggers

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