Re: truncate in combination with deferred triggers
От | Tom Lane |
---|---|
Тема | Re: truncate in combination with deferred triggers |
Дата | |
Msg-id | 5867.1156186614@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | truncate in combination with deferred triggers (Markus Schiltknecht <markus@bluegap.ch>) |
Ответы |
Re: truncate in combination with deferred triggers
|
Список | pgsql-bugs |
Markus Schiltknecht <markus@bluegap.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
В списке pgsql-bugs по дате отправления: