On Thu, Mar 12, 2015 at 10:36 PM, Stephen Frost <sfr...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to