From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:11:06 |
Message-ID: | 200305201111.06472.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
> > 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.
No, I suppose not; what David really needs is GRANT ALTER; including GRANT
DROP just seemed consistent.
> > 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?)
Hmmm .... yeah, that sounds non-trivial.
David is going to talk with Joe about doing some special logging for DDL
operations; if they come out of it with some clean code, would you consider a
patch that includes an new logging option for "log_ddl" ?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-20 18:16:57 | Re: Suggestion GRANT ALTER, TRIGGER ON ALTER |
Previous Message | Tom Lane | 2003-05-20 18:04:04 | Re: Suggestion GRANT ALTER, TRIGGER ON ALTER |