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
