Re: CATUPDATE confusion?

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Any other opinions?
> > The options are:
> > 0) Leave as is.
> > 1) Remove catupdate and replace with superuser checks.
> > 2) Remove catupdate and rely on regular table permissions on catalogs.
>
> I think I vote for (1). I do not like (2) because of the argument I made
> upthread that write access on system catalogs is far more dangerous than
> a naive DBA might think. (0) has some attraction but really CATUPDATE
> is one more concept than we need.

I agree with #1 on this.

> On the other hand, if Stephen is going to push forward with his plan to
> subdivide superuserness, we might have the equivalent of CATUPDATE right
> back again. (But at least it would be properly documented and
> supported...)

The subdivision of superuserness is intended only for operations which
can't be used to directly give the user superuser access back and
therefore I don't think we'd ever put back CATUPDATE or an equivilant.

I'd much rather reduce the need for direct catalog modifications by
adding additional syntax for those operations which can't be done
without modifying the catalog directly and, where it makes sense to, add
a way to control access to those operations.

For example, changing a database to not accept connections seems like
something the database owner should be allowed to do. Perhaps that'd be
interesting to allow users other than the owner to do, perhaps it
doesn't, but that would be an independent question to address.

Thanks!

Stephen