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 <j...@garrett-is.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 <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 >> > > >
