I'd reported a few years ago what seemed an inconsistency with the TRIGGER permission on tables where it allows a role to create a trigger but not to drop it. I don't have the original email to reply directly to the thread anymore, but I've moved on to actually trying to fix it myself, hence sending to this list instead.
Original thread - http://www.postgresql.org/message-id/e1tead4-0004le...@wrigleys.postgresql.org I found RemoveTriggerById() in backend/commands/trigger.c which seems to be the code that actually drops the trigger. And I see in CreateTrigger() above it how to use pg_class_aclcheck() to check for valid permissions, so I was going to see about adding that code to the Remove section. However, I see no code in Remove for checking for object ownership, so I'm not sure how that is being enforced currently which would also have to be adjusted. I see down in RangeVarCallbackForRenameTrigger() that it uses pg_class_ownercheck() to do so, but can't find where that is being done for dropping a trigger. I've tried tracing the function calls in RemoveTriggerById() to see if one of them is doing the owner check, but I haven't been able to see it. The only other reference to RemoveTriggerById() I can find is in backend/catalog/dependency.c and I don't see the check there either. This is my first time really digging into the postgres core code to try and adjust something myself. Even if there's no interest in accepting a patch for this, I would appreciate some guidance on how to go about it. Thanks! -- Keith Fiske Database Administrator OmniTI Computer Consulting, Inc. http://www.keithf4.com
