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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2006-08-21 20:43:58 | Re: truncate in combination with deferred triggers |
Previous Message | Markus Schiltknecht | 2006-08-21 18:24:12 | truncate in combination with deferred triggers |