Re: PgAdmin browses all tables, even those not allowed

I hearby place my vote for allowing us to hide schemas and tables that a
user has no priviliges on (and columns too would be useful but of
secondary importance). I believe this is a PostgreSQL request and not a
pgAdmin3 request. I regularly get complaints from users of my Data
Warehouses that it is a pain for them to have to wade through lists of
schemas / tables that they are not interested in (stage tables, system
catalog, etc...) to get to their tables. I know some reporting tools
allow for the customization of the views users see, but it would be
appropriate to put it at the database level so users see the same thing
regardless of what tools they are using to access it. I believe I've
seen a response in the past that this is no way to implement security
and that it will not be worked on. This is not a security request, it
is an end-user experience improvement request.

Maybe implement row-level security on the system tables? I'll let you
who are smarter than me figure out how, but my vote is now cast.

Joe Garrett

On 1/19/2010 1:05 PM, Guillaume Lelarge wrote:
> Le 19/01/2010 13:36, F T a écrit :
>
>> Hello list,
>>
>> I use pgAdmin1.10.0, Windows XP, PostgreSQL 8.2.
>>
>> If I connect to my database with pgAdmin, using a connexion role that is
>> not allowed to access some tables, I see thoses tables in the list (but I
>> get a right error if I click it).
>>
>> Is there a solution that pgAdmin shows a table list with only the tables the
>> connexion role is allowed to access?
>>
>>
> Right now, we display every tables available in the database. There are
> no security issues here, you'l have the same issue with psql.
>
> However, it doesn't feel right to show tables and gets errors with a
> simple click on it. I'm not sure the best way to deal with this is to
> hide the tables (should we also hide the columns if the user is not
> allowed to access some of them?). Actually, I think we need to better
> handle this, but this will be a big work. Interesting, but lots of work.
>
>
>