Re: Suggestion GRANT ALTER, TRIGGER ON ALTER

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 BerkusAglio Database SolutionsSan Francisco