Re: CATUPDATE confusion?

Robert,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost <sfrost(at)snowman(dot)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