On Oct 10, 2008, at 5:16 PM, Christopher Maier wrote:
On Oct 10, 2008, at 4:53 PM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Looks like you should revoke DELETE privilege from plain users, and
have your delete trigger be a security definer function. There
would be
another security definer function to delete non-deduced rows which
users
can call directly.
That seems overly complicated to use.
If the triggers that are privileged to delete deduced rows run as a
special user, couldn't the validation triggers look at CURRENT_USER
to see whether to allow the delete of a deduced row or not?
regards, tom lane
That sounds like the best approach, Tom. I've already implemented
Alvaro's suggestion, which works nicely. It should be a simple
matter to add in the current_user check. I'll give that a whirl and
see how it goes.
Thanks for all the great suggestions, everyone.
Chris
Just for completeness, and for posterity, this solution (checking for
CURRENT_USER) works great. I don't need to revoke DELETE privileges
from anyone; simply define all my triggers that kick off a DELETE
operation as SECURITY DEFINER (created by my privileged user role),
and then have a BEFORE DELETE trigger that compares the value of
CURRENT_USER to this privileged user's name. Works great, and is very
easy to implement.
Thanks for the help!
--Chris
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
