I had intended to send this message to the pgsql-hackers mailing list as well.
Thanks, - Ryan ---------- Forwarded message ---------- From: Ryan Bradetich <[EMAIL PROTECTED]> Date: Mon, Sep 1, 2008 at 2:20 PM Subject: Re: [HACKERS] [Patch Review] TRUNCATE Permission To: Tom Lane <[EMAIL PROTECTED]> Hello Tom, On Mon, Sep 1, 2008 at 1:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ryan Bradetich" <[EMAIL PROTECTED]> writes: > >> I do not believe this is a huge issue since truncate is prohibited on > the > >> system catalogs > >> by the truncate_check_rel(). > > Only when allowSystemTableMods is false. I think it would be a serious > mistake for your patch to treat the system catalogs differently from > other tables. > Good Point. Looks like I still have more code reading to do :) This is Robert Haas's patch for the September 2008 commit-fest. I am just offering my review. Gives me a good excuse to dig into the PostgreSQL code base. Hopefully this review is useful to the person committing the patch. > > Here is the inconsistency I observed: > > It seems to me that you are assuming that lack of a TRUNCATE permission > bit is the only valid reason for a "permission denied" failure. This is > fairly obviously not so, since multiple permissions typically enter into > any command (consider schema-level permissions for instance). > I was just comparing the behavior between DELETE and TRUNCATE. My last suggestion for the TRUNCATE permission always being removed on the system tables is obviously bogus because of the allowSystemTableMods issue you raised. Does my first suggestion still make sense for removing the TRUNCATE in pg_class_aclmask() when pg_Authid.rolcatupdate is not set? Thanks, - Ryan
