Re: Re: PgAdmin browses all tables, even those not allowed

When I say end-user I am thinking from a Data Warehouse perspective
where there are many SELECT-only users. For them, their experience is
frustrating and confusing when they need to go through many schemas and
tables that they don't care about to find what they can access. That is
why I suggested this is more of a PostgreSQL request than a pgAdmin3
request, since this type of end-user is often not writing SQL, but is
using some other tool that helps them build a query. This type of user
does not care to see the system schemas, or staging schemas, or personal
user schemas. There are many more of this type of user in a Data
Warehouse situation than developer-users who write SQL, and the
experience of using the Data Warehouse would be enhanced by the ability
at the database level to tie the list of schemas and tables to their
privileges.

Even if we can't control the view of the tables, it would be very
helpful to control the viewing of schemas. At least that way the users
would only see the one schema they are interested in.

I think for the developer type of user it would also be nice to allow
the ability to hide schemas and tables they can not access, but to me
this is not that big of a deal, since they should know exactly how to
find what they are looking for. However, to answer your point about not
seeing what tables there are so they can't know if they can create one,
I would say that if a developer has CREATE ability in a schema, then I
would expect they at least have SELECT on all the tables in that schema.

As a last note, since I have only a post or two here on this list so
far, please allow me to say that I love the pgAdmin3 tool, and I
congratulate you on the fine work. I especially like the Server Status
where you can see what's happening in the database.

Joe

On 1/20/2010 4:45 AM, F T wrote:
>
> 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 <mailto:dpage(at)pgadmin(dot)org>>
>
> On Tue, Jan 19, 2010 at 8:57 PM, Joe Garrett <joe(at)garrett-is(dot)com
> <mailto: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
> <mailto:pgadmin-support(at)postgresql(dot)org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support
>
>
>