There's a generic trigger that sends a signal to a process whenever changes are made (via listen/notify mechanism), but when FK cascade fires it will cause a mass amount of notifies to be send out and I want to avoid it. 2011/3/18 David Johnston <polobo@xxxxxxxxx>: > Don't know if this would work but could you check to see if the corresponding PK exists on A? > > It may also help to explain why you would want to do such a thing so that someone may be able to provide an alternative solution as opposed to simply responding to a generic feature question. > > David J. > > -----Original Message----- > From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Grzegorz Jaskiewicz > Sent: Thursday, March 17, 2011 6:41 PM > To: pgsql-general@xxxxxxxxxxxxxx > Subject: triggers and FK cascades > > Considering the following example. > Tables A and B. > Table A contains some data. > Table B reefers to table A using FK with 'on delete cascade'. Table B has a trigger on it, after delete per row > > Now, is there any way I can tell in the trigger on table B that it has been called from a direct delete on that table, as oppose to the indirect (FK) delete on table A? > > Trigger is PLpg/SQL or C function. > > > -- > GJ > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > > -- GJ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
