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