RE: select * from pgadmin_users; causes error
От | Dave Page |
---|---|
Тема | RE: select * from pgadmin_users; causes error |
Дата | |
Msg-id | 8568FC767B4AD311AC33006097BCD3D61A29CA@woody.vale-housing.co.uk обсуждение исходный текст |
Ответ на | select * from pgadmin_users; causes error (John Hatfield <jhatfield@g-s.com.au>) |
Список | pgsql-admin |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 23 February 2001 22:29 > To: Dave Page > Cc: jhatfield@g-s.com.au; 'PostgreSQL Admin News' > Subject: Re: [ADMIN] select * from pgadmin_users; causes error > > > Dave Page <dpage@vale-housing.co.uk> writes: > > Basically it isn't so much as the user ID that created > > the views that is an issue, it's that fact that pgAdmin > >> then didn't issue a > >> 'GRANT ALL ON pgadmin_users TO PUBLIC'. > >> > >> The particular case being complained of here would not be > >> fixed by that. > >> > > > What exactly was the problem? > > The problem was that pgadmin was first started in a > particular database > by a non-privileged user. So it created the pgadmin_users > view as owned > by that non-privileged user. Then the view does not work, > even for the > superuser, because its attempt to access pg_shadow is checked > under the > permissions of its owner not of the invoker. Hmm yes. I've just been playing with it and that is exactly the case. > Deleting and recreating the view (to make it owned by the superuser) > will fix this problem, and I'm glad to hear that pgadmin provides a > reasonably painless way to do that. But the average Joe > isn't going to > realize what the problem is or what he has to do to fix it. It'd be > better if the problem couldn't occur in the first place. If > you really > need a view on pg_shadow, can you postpone creating it until > you are run > as superuser? That shouldn't be a major problem, I'll look into it for the next release. Regards, Dave.
В списке pgsql-admin по дате отправления: