Josh Berkus <josh@agliodbs.com> writes:
> Well, that puts us back in the position of requiring a "read" or "metadata"
> permission for tablespaces, or requiring superuser access. The latter is
> unpalatable because there are existing tools in the field which work without
> superuser access; the former is troublesome because it wouldn't be used for
> anything other than the dbsize function, at least not right now.
Well, what about something like the following:
* no restriction on table-size function (on the grounds that you could
look into pg_class)
* no restriction on database-size function *when applied to the current
database* (again, you could look into pg_class); to apply to some other
database, you must have connect privileges. (Actually, on the
assumption that you must have connect privs to current DB, I guess we
could simplify that to connect privs on target DB, full stop.)
* tablespace-size function requires being owner of current DB.
There is nothing particularly principled about the last choice, but
it's not superuser and not wide open either.
Another option for tablespace-size is that you must have CREATE on the
target tablespace. This is also not real principled, since CREATE is
more of a "write" privilege than a "read" one, but it'd at least give
DBAs some tool to work with.
Also, I don't see anything very wrong with defining USAGE on a
tablespace to mean that you can use the tablespace-size function on it.
AFAIR the overhead for allowing an existing privilege keyword to apply
to another type of object is just about nil --- a couple macro changes.
With any of these three options, the tablespace-size function would
change from "allowed to anyone" to "not allowed by default", unless you
happened to be the DB owner. Not sure which would be preferable from
the point of view of those existing tools you mention.
regards, tom lane