There are actually TWO tables involved: the table upon which 
the trigger will actually fire, and some other table which is 
mentioned in passing in the trigger definition.  It's possible that 
the locking requirements for the secondary table are weaker since I 
don't think the presence of the trigger actually affects runtime 
behavior there.  However, there's probably little point in try to 
weaken the lock to less than the level required for the main table 
because a foreign key involves adding referential integrity triggers 
to both tables. 

View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to