"Ryan Bradetich" <rbradetich@gmail.com> 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?