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 <dp...@pgadmin.org>

On Tue, Jan 19, 2010 at 8:57 PM, Joe Garrett <j...@garrett-is.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support
>

Reply via email to