From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org> |
Subject: | Re: Suggestion GRANT ALTER, TRIGGER ON ALTER |
Date: | 2003-05-20 18:04:04 |
Message-ID: | 410.1053453844@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Therefore I propose the following two additional permissions on
> TABLEs, VIEWs, and FUNCTIONs:
> GRANT ALTER ON object TO user : allows the user to run ALTER or REPLACE
> statements on the object;
> GRANT DROP ON object TO user : allows the user to DROP the object (obviously a
> permission that could only be used once).
ALTER permission seems reasonable, I'm less convinced that GRANT DROP is
really needed.
> Accompanying these should be an extension of triggers to allow logging, etc.,
> of such activity. Namely:
> CREATE TRIGGER tg_name {BEFORE|AFTER} ALTER ON table
> CREATE TRIGGER tg_name BEFORE DROP ON table
These I do not like. We do not run user triggers in the midst of
catalog operations because they might see inconsistent states of the
system catalogs. (Consider for instance the possibility that a table is
being dropped as part of a cascaded drop, and something it depends on is
already gone. What does the trigger see? Does it still work?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-05-20 18:11:06 | Re: Suggestion GRANT ALTER, TRIGGER ON ALTER |
Previous Message | Oleg Bartunov | 2003-05-20 17:36:00 | Re: Heads up: 7.3.3 this Wednesday |