Re: PgAdmin browses all tables, even those not allowed

Thank for your answer.

There are advantages / disavantages for end-users with the 2 solutions

Solution 1:
Let the end-user see only the schemas/tables he is allowed to use (as Oracle
SQL Developper does, for example) :
+ : easy to retrieve their data without been lost if the database
has a lot of schemas/tables
- : if the end user tries to create a table, he won't know the
possible existence of the table before his request fails.

Solution 2 (actual behaviour) :
Let the end user see only all the schemas/tables of the database
+ : before trying to create a table, you can see what already
exists
- : it may be hard to retrieve their tables if the database has
a lot of schemas/tables, and the end user knows if he can view or use the
data only after he has click on a table and received an error message.

Fabrice

2010/1/20 Dave Page <dpage(at)pgadmin(dot)org>

On Tue, Jan 19, 2010 at 8:57 PM, Joe Garrett <joe(at)garrett-is(dot)com> wrote:
> > 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.
>
> It'll make end-user experience a whole lot worse because there will be
> no way to tell if a table you're about to try to create already
> exists.
>
> The recommended way to do this is to use per-user schemas, and filter
> them as required in pgAdmin.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
>
> --
> Sent via pgadmin-support mailing list (pgadmin-support(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support
>