On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost <sfrost@snowman.net> wrote:
> 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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company