Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost <sfr...@snowman.net> wrote: > > Basically, in my view at least, these programs are likely to continue to > > use these backwards compatibility views until we either formally > > deprecate them or (more likely) until we actually remove them and things > > break. As such, I'm not sure if this information really helps us make a > > decision here. > > After poking at this a bit, I am guessing the reason they still use > pg_user is that regular users don't have permission to access > pg_authid directly. We don't want to make it impossible for pgAdmin > to work for non-superusers.
I should have been more specific. I don't believe they've moved to using pg_roles completely (which was created specifically to address the issue that regular users can't select from pg_authid). Both of the tools being discussed use pg_roles also (and, in fact, I believe they have to for certain fields which pg_user doesn't include.. rolcreaterole being a pretty big one, but also rolconnlimit and rolinherit, which wouldn't make sense in pg_user anyway..). I agree that they can't simply move to pg_authid today since only superusers have access to that table today. Of course, with column-level privileges, we could potentially change that too.. In any case, looking at this again, it seems clear that we've not been keeping pg_user up to date and no one seems to care. I don't think it makes sense to go back and try to add "useconnlimit", "usecanlogin", "usecreateuser" for 9.5 when pg_user was only ever intended for backwards compatibility and clearly hasn't been getting the love and attention it would deserve if it was really useful. As such, I'm coming down on the side of simply removing pg_user, pg_shadow, and pg_group for 9.5. Having a half-maintained mish-mash of things from pg_authid making their way into pg_user/pg_shadow (which suffers all the same problems of missing important fields) isn't doing anyone any favors, and pg_group is an inefficient way of getting at the information that's in pg_auth_members which implies that groups are somehow different from roles, which hasn't been the case in 10 years. Thanks! Stephen
signature.asc
Description: Digital signature