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

I don't think the assumption that CREATE implies SELECT is a good one. It is
probably true in most cases, but there might be folks that have set it up
otherwise.

It seems that the Dependents tab on a role under the Login Roles might be
the place to look for tables, etc, that the login has access to ....

On Wed, Jan 20, 2010 at 7:16 AM, Joe Garrett <joe(at)garrett-is(dot)com> wrote:

> 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>
>
> 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
>>
>
>
>