On Sat, Dec 27, 2014 at 6:31 PM, Noah Misch <noah@leadboat.com> wrote:
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > >> Plan C (remove CATUPDATE altogether) also has some merit. But adding a > >> superuser override there would be entirely pointless. > > > This is be my recommendation. I do not see the point of carrying the > > option around just to confuse new users of pg_authid and reviewers of > > the code. > > Yeah ... if no one's found it interesting in the 20 years since the > code left Berkeley, it's unlikely that interest will emerge in the > future.
No objection here.
Given this discussion, I have attached a patch that removes CATUPDATE for review/discussion.
One of the interesting behaviors (or perhaps not) is how 'pg_class_aclmask' handles an invalid role id when checking permissions against 'rolsuper' instead of 'rolcatupdate'. This is demonstrated by the 'has_table_privilege' regression test expected results. In summary, 'has_rolcatupdate' raises an error when an invalid OID is provided, however, as documented in the source 'superuser_arg' does not, simply returning false. Therefore, when checking for superuser-ness of an non-existent role, the result will be false and not an error. Perhaps this is OK, but my concern would be on the expected behavior around items like 'has_table_privilege'. My natural thought would be that we would want to preserve that specific functionality, though short of adding a 'has_rolsuper' function that will raise an appropriate error, I'm uncertain of an approach. Thoughts?