Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Apr 2, 2015 at 12:53 AM, Stephen Frost <sfr...@snowman.net> wrote: > > Clearly, further testing and documentation is required and I'll be > > getting to that over the next couple of days, but it's pretty darn late > > and I'm currently getting libpq undefined reference errors, probably > > because I need to set LD_LIBRARY_PATH, but I'm just too tired to now. :) > > > > Thoughts? > > The tricky part of this seems to me to be the pg_dump changes. The > new catalog flag seems a little sketchy to me; wouldn't it be better > to make the dump flag into an enum, DUMP_EVERYTHING, DUMP_ACL, > DUMP_NONE?
I agree that the pg_dump changes are a very big part of this change. I'll look at using an enum and see if that would work. > Is this creating a user-visible API break, where pg_stat_activity and > pg_stat_replication now always show only the publicly-visible > information, and privileged users must explicitly decide to query the > _all versions? If so, -1 from me on that part of this. Thanks for bringing it up. No, the existing API is exactly the same for the existing views- the only difference is that now there are _all versions which provide unfiltered data (but you have to have permission to call the _all() functions underneath, or you get a permission denied error). Where this does have an API change is with the simpler functions that used to do "if (superuser() || replication_role())" and now depend on the GRANT system instead. We can't (today, at least) say: GRANT EXECUTE ON function_whatever() TO replication_roles; And have that be kept current as that role attribute is modified. I've not done it yet, but we could certainly have pg_dump dump out GRANTs for the *current* users which have that role attribute and give those users access to the functions via the normal permissions system. I'm not really sure that's a good idea though- it might be better to have a clean break here (and one which is clearly in the "more secure/explicit" direction) and tell admins in the release notes to GRANT EXECUTE on the functions for the roles they want to give permission to. We could also duplicate the functions and have the existing ones remain as-is and have the new ones just depend on the GRANT system, but I don't particularly like that since I'm afraid we'd end up in the same boat we're in now with pg_user and friends. Thanks! Stephen
Description: Digital signature