there are no users and groups in postgres anymore (> 8.2?), there are only ROLE
s, roles may or may not be able to login. Not that this matters much as CREATE USER
and CREATE GROUP
are just aliases for CREATE ROLE
.
As @Peter Eisentraut says this code should work fine.
Some of the bigger differences I noticed in this area, outside of the fact that Postgres uses Roles, instead of users, is the way Postgres authenticates users to databases using ident which can allow system users to access databases without passwords, via a system user -> posgres user mapping, why by default maps them if they're equivalent. For more on Authentication, see the auth method documentation.
As far as table permissions, to my knowledge they are pretty close to the same. However you can make your permissions much more fine grained in postgres. Now in postgres you can even restrict users to specific columns using GRANT
and in some coming version, it should be able to restrict database users by row.
I do absolutely suggest restricting different apps by different user/database parings, though you can also use SCHEMA
's instead of databases, though if you own a schema, you can modify anything in it, so it's not quite a fine grained.
Any best practices will probably depend on your app, really you should go read the docs and figure out what is best for that App.
You are correct you cannot use indexed views. Sadly what you have here is a business problem not a database problem. If you need to know the PKs and indexes from the other database and you don't have even viewing access, then require the DBAs who do have that access to provide the information you need to do your job or require them to write and performance tune the queries. No one should be writing queries against a database they do not have access to. If they won't give you access, then the work belongs to them too. I would have my boss talk to their boss and ask them to solve this set of problems for you. They created the problem it's up to them to fix it.
Best Answer
Here is the definition of information_schema.views:
Here is how you can count the views per database per user
I am not that sure about access/denial of views. In the
information_schema.views
table, there is field calledSECURITY_TYPE
(which have valuesDEFINER
andINVOKER
).If a View has
SECURITY_TYPE
asINVOKER
, everybody and his grandmother canSELECT
from that View. My guess is that you would have to set theSECURITY_TYPE
toDEFINER
to restrict everyone from running aSELECT
from that View. Of course any user withSUPER
privilege and the definer can aSELECT
on that View.Changing the
SECURITY_TYPE
is a little painful.You can mysqldump all views. Here is a post I made back on July 26, 2011 : Modify DEFINER on Many Views. @DTest had an even more concise answer using ALTER VIEW.
Edit the output file in vi or some other editor to change the
SECURITY TYPE
of any View you wish. Then, jus reimport the view from that text file.Give it a Try !!!