Is the following a safe way to revoke all rights from all users and groups on a
table or view (TABLEORVIEWNAME)?update pg_class set relacl=null where
relname='TABLEORVIEWNAME';
David Legault escribió:
> It's marked with an % saying it's easy to implement, but isn't with a "-" so
> it won't be in 8.3.
Note that having a "-" in front means "somebody already coded it and the
patch has been committed". Not having it does not mean it won't be in
8.3; it means nobody has don
Will report on it,
There isn't anything in the FAQ about changes to the ROLES that I've seen
though this line may be interesting:
%Allow GRANT/REVOKE permissions to be applied to all schema objects with one
command
The proposed syntax is:
GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT
David Legault wrote:
I'll test all that [EMAIL PROTECTED] stuff and see what happens and if it works
properly and report back on it.
Excellent - never used it myself.
Is there a place where I can see what features were suggested and where I
could suggest my own?
Full list, and what people a
I only have a local root user for DBA pruposes, the rest will be DB specific
roles (If I can do it properly).
Users have no privileges except CONNECT to the DB. All the privileges are
granted to group roles.
Users are assigned groups to have access to DB functionality which are all
stored in fun
David Legault wrote:
From the docs
db_user_namespace (boolean)
It doesn't talk about this in the CREATE ROLE docs though so it's a bit
ambiguous and the note saying this is a temp measure means they are
thinking
of something better for the future I assume.
Well, it's clearly not ideal, b
From the docs
db_user_namespace (boolean)
This parameter enables per-database user names. It is off by default. This
parameter can only be set in the postgresql.conf file or on the server
command line.
If this is on, you should create users as [EMAIL PROTECTED] When username is
passed by a con
David Legault wrote:
Concerning the pg_hba.conf file, I don't want to prevent external
connections to the DB as I need all my web apps to connect to them. I was
referring the fact that ROLE A "belongs" to DB G so that I don't want
him to
access anything in DB H for example.
I'd like to be able
Concerning the pg_hba.conf file, I don't want to prevent external
connections to the DB as I need all my web apps to connect to them. I was
referring the fact that ROLE A "belongs" to DB G so that I don't want him to
access anything in DB H for example.
I'd like to be able to create roles that ca
David Legault wrote:
In which table pg_* are stored the GRANT options? As I can do a cross-check
with a SELECT to see if the user has any grants on functions using the
pg_proc table. At the same time, I need to know exactly the names of the
functions to be able to REVOKE them which in my opinion,
In which table pg_* are stored the GRANT options? As I can do a cross-check
with a SELECT to see if the user has any grants on functions using the
pg_proc table. At the same time, I need to know exactly the names of the
functions to be able to REVOKE them which in my opinion, there should be a
wil
David Legault wrote:
Hello,
Is there a way to revoke all privileges of a role without actually
specifying the whole list of items.
Like if a role has privileges on FUNCTIONs, is there a REVOKE all
FUNCTIONS.
There's no GRANT/REVOKE ON public.* command format, but there are
plenty of plpgsq
Hello,
Is there a way to revoke all privileges of a role without actually
specifying the whole list of items.
Like if a role has privileges on FUNCTIONs, is there a REVOKE all FUNCTIONS.
Is there a way to check if it has a GRANT in a particular type (CONNECT,
FUNCTION, TRIGGER) before calling th
13 matches
Mail list logo
