While reviewing the supporting documentation and functions for role
attributes I noticed that there seems to be some confusion (at least for
me) with CATUPDATE.

This was prompted by the following comment from Peter about
'has_rolcatupdate' not having a superuser check.

So, where I find this confusing is that the documentation supports this
functionality and the check keeps superuser separate from CATUPDATE...
however... comments and implementation in user.c state/do the opposite and
couple them together.

Documentation: - "Role
can update system catalogs directly. (Even a superuser cannot do this
unless this column is true)"


/* superuser gets catupdate right by default */
new_record[Anum_pg_authid_rolcatupdate - 1] = BoolGetDatum(issuper);


 * issuper/createrole/catupdate/etc
 * XXX It's rather unclear how to handle catupdate.  It's probably best to
 * keep it equal to the superuser status, otherwise you could end up with
 * a situation where no existing superuser can alter the catalogs,
 * including pg_authid!
if (issuper >= 0)
  new_record[Anum_pg_authid_rolsuper - 1] = BoolGetDatum(issuper > 0);
  new_record_repl[Anum_pg_authid_rolsuper - 1] = true;

  new_record[Anum_pg_authid_rolcatupdate - 1] = BoolGetDatum(issuper > 0);
  new_record_repl[Anum_pg_authid_rolcatupdate - 1] = true;

Perhaps this is not an issue but it seemed odd to me, especially after
giving Peter's comment more thought.  So, I suppose the question is whether
or not a superuser check should be added to 'has_rolcatupdate' or not?  I
believe I understand the reasoning for coupling the two at role
creation/alter time, however, is there really a case where a superuser
wouldn't be allowed to bypass this check?  Based on the comments, there
seems like there is potentially enough concern to allow it.  And if it is
allowed, couldn't CATUPDATE then be treated like every other attribute and
the coupling with superuser removed?  Thoughts?


Adam Brightwell -
Database Engineer -

Reply via email to