Re: AfterTriggerSaveEvent() Error on altered foreign key cascaded delete
| От | Tom Lane |
|---|---|
| Тема | Re: AfterTriggerSaveEvent() Error on altered foreign key cascaded delete |
| Дата | |
| Msg-id | 24945.1477510973@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | AfterTriggerSaveEvent() Error on altered foreign key cascaded delete (James Parks <james.parks@meraki.net>) |
| Ответы |
[BUGS] Re: AfterTriggerSaveEvent() Error on altered foreign key cascadeddelete
|
| Список | pgsql-bugs |
James Parks <james.parks@meraki.net> writes:
> I *believe* we've found a slight inconsistency with the handling of foreign
> keys in the situation of cascaded deletes. Here is a POC to motivate the
> discussion:
> ...
> -- Method A
> -- ALTER TABLE bar ADD CONSTRAINT foo_fkey FOREIGN KEY (foo_id) REFERENCES
> foo (id) ON DELETE CASCADE ON UPDATE NO ACTION DEFERRABLE INITIALLY
> DEFERRED;
> -- Method B
> ALTER TABLE bar ADD CONSTRAINT foo_fkey FOREIGN KEY (foo_id) REFERENCES foo
> (id) ON DELETE CASCADE ON UPDATE NO ACTION;
> ALTER TABLE bar ALTER CONSTRAINT foo_fkey DEFERRABLE INITIALLY DEFERRED;
> If you run the above code, you should get something like this:
> psql:test.sql:24: ERROR: AfterTriggerSaveEvent() called outside of query
> CONTEXT: SQL statement "DELETE FROM ONLY "public"."bar" WHERE $1
> OPERATOR(pg_catalog.=) "foo_id""
> However, if you swap out the foreign key constraint initialization methods
> (see "Method A" and "Method B" above) the AfterTriggerSaveEvent() error
> disappears:
Hm. A quick test suggests that Method B leaves the deferrability flags
for the FK's triggers set incorrectly. That's a bug for sure. I'm not
certain offhand if the error message indicates an additional problem
(ie, should the triggers work when set up this way?)
regards, tom lane
В списке pgsql-bugs по дате отправления: