Re: pg_ls_dir & friends still have a hard-coded superuser check

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Also, the same argument could be made about removing the built-in
> superuser check from ANY function, and we've already rejected that
> argument for a bunch of other functions. If we say that argument is
> valid for some functions but not others, then we've got to decide for
> which ones it's valid and for which ones it isn't, and consensus will
> not be forthcoming. I take the position that hard-coded superuser
> checks stink in general, and I'm grateful to Stephen for his work
> making dump/restore work properly on system catalog permissions so
> that we can support better alternatives. I'm not asking for anything
> more than that we apply that same policy here as we have in other
> cases.

I went over *every* superuser check in the system when I did that work,
wrote up a long email about why I made the decisions that I did, posted
it here, had follow-on discussions, all of which lead to the patch which
ended up going in.

I am not anxious to revisit that decision and certainly not based on
an argument that, so far, boils down to "I think a monitoring system
might be able to use this function that allows it to read pg_authid
directly, so we should drop the superuser() check in it."

Thanks!

Stephen