Trigger and permissions

Now for something completely different

    Somewhere  in  the  Oracle  doc's  I read that a trigger when
    fired is executed under the permissions of the trigger owner.
    That makes really sense for me. This way a normal user can be
    revoked from modifying a table directly, but if  he  modifies
    another  table  where he has permissions for, a trigger fired
    for that update can access the protected table. Good  feature
    on  logging  tables,  so joe-user can delete a customer but a
    trigger will log that and joe-user cannot modify the log.

    In PostgreSQL, triggers are currently executed under the same
    username  as the one caused it to fire. So the user must have
    the proper permissions on the tables,  the  trigger  touches,
    too.

    I'm  not  sure  if  changing the current database user in the
    backend for the time a trigger function is  active  is  easy.
    Looks  like  all  the  permissions  are  checked against what
    GetPgUserName() returns.  But I'm not sure if this is true in
    all places that a trigger can invoke.

    I  think  it  would  be nice to to have something like setuid
    triggers. Some triggers cause a change of the user  and  some
    don't.  A  setuid_user  attribute in pg_trigger could do that
    job.  If that doesn't  contain  NULL,  the  trigger  will  be
    invoked  under  the  permissions  of  the user in that field.
    Obviously to say that a normal user can  only  create  setuid
    triggers with his own name.

    Should  the  syntax  for  CREATE  TRIGGER be extended here or
    should we have a completely different command for that?

    Any suggestions/comments?


Until later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #