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.
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?
regards, tom lane
