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: http://www.postgresql.org/mailpref/pgsql-hackers