All, * Stephen Frost (sfr...@snowman.net) wrote: > In particular, the pg_logical_* functions have superuser checks and > those checks also allow roles who have the replication role attribute. > That isn't something we can represent with the GRANT system currently.
I chatted with Andres a bit at PGConf.NY regarding the pg_logical_* and the REPLICATION role attribute in general. This is all 9.7 material, of course, but I wanted to jot down my recollection of the discussion before it goes out of mind. The idea we came up with is to have a pg_replication default role which essentially replaces the REPLICATION role attribute. Andres didn't see it as being terribly valuable to disallow a role with the REPLICATION attribute from logging into the database directly, if it's allowed to do so by pg_hba.conf. If the administrator doesn't wish to allow that, then they can configure pg_hba.conf to not allow it. Further, with the permissions handled by the GRANT system, the administrator could have independent roles for connecting to the replication protocol and for running the pg_logical_* functions, again, if they wish to configure their system that way. Lastly, Andres felt that we could keep the syntax for setting/unsetting the role attribute and just convert those into GRANT/REVOKE statements for the pg_replication role. I'm not thrilled with that idea as it feels a bit unnecessary at this point, given the relatively few users of pg_logical_* functions by tools and because it would introduce a one-off hack in tools such as pgAdmin, which would have to query pg_auth_members to get the current setting of the REPLICATION role attribute, even if the code for granting/revoking that role attribute doesn't change, unless we also hack up the views and tables which contain role attributes today to reflect membership in pg_replication as having (or not) that role attribute. Basically, for my 2c, it seems like an awful lot of extra code on the backend side for relatively small gain. pgAdmin and similar tools are going to want to provide support for default roles in any case, along with their role attributes support, and it doesn't seem useful to try and conflate the two. Andres, please correct me if any of the above is incorrect. Thoughts and comments are welcome, of course. Thanks! Stephen
signature.asc
Description: Digital signature
