Re: CATUPDATE confusion? - Mailing list pgsql-hackers

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Sat, Mar 7, 2015 at 6:40 PM, Adam Brightwell
> <adam.brightwell@crunchydatasolutions.com> wrote:
> >> pg_shadow, pg_user and pg_group were added when role support was added,
> >> specifically for backwards compatibility.  I don't believe there was
> >> ever discussion about keeping them because filtering pg_roles based on
> >> rolcanlogin was too onerous.  That said, we already decided recently
> >> that we wanted to keep them updated to match the actual attributes
> >> available (note that the replication role attribute modified those
> >> views) and I think that makes sense on the removal side as well as the
> >> new-attribute side.
> >>
> >> I continue to feel that we really should officially deprecate those
> >> views as I don't think they're actually all that useful any more and
> >> maintaining them ends up bringing up all these questions, discussion,
> >> and ends up being largely busy-work if no one really uses them.
> >
> > Deprecation would certainly seem like an appropriate path for 'usecatupd'
> > (and the mentioned views).  Though, is there a 'formal' deprecation
> > policy/process that the community follows?  I certainly understand and
> > support giving client/dependent tools the time and opportunity to update
> > accordingly.  Therefore, I think having them read from 'rolsuper' for the
> > time being would be ok, provided that they are actually removed at the next
> > possible opportunity.  Otherwise, I'd probably lean towards just removing
> > them now and getting it over with.
>
> Unless some popular tool like pgAdmin is using these views, I'd say we
> should just nuke them outright.  If it breaks somebody's installation,
> then they can always recreate the view on their particular system.
> That seems like an adequate workaround to me.

As near as I can tell, pgAdmin3 does still use pg_user (though I don't
think it uses pg_group or pg_shadow except when connected to an ancient
server) in some cases.  Where it is used, based on my quick review at
least, it looks like it'd be pretty easy to fix.

The rolcatupdate usage appears to all be associated with pg_authid
though, and the changes required to remove the places where it shows up
doesn't look particularly bad either.  There are no references to
usecatupdate.  Where there are references to 'use*', they'd have to also
be updated with the change to pg_user, naturally.

Looking at phppgadmin, there are quite a few more uses of pg_user there,
along with references to pg_group and even pg_shadow (for 8.0 and
earlier backends).  Amusingly, the only place 'catupdate' is referenced
there is in the Polish language file.  Updating phppgadmin to not
reference pg_user or the other views looks like it'd be a bit more work,
but not a huge effort either.

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.
Thanks!
    Stephen