Josh Berkus <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate