Re: create role - Mailing list pgsql-sql

From Adrian Klaver
Subject Re: create role
Date
Msg-id 201012310905.35527.adrian.klaver@gmail.com
Whole thread Raw
In response to Re: create role  (tcapobianco@prospectiv.com)
Responses help needs in converting db2 function in postgresql.
List pgsql-sql
On Friday 31 December 2010 8:22:23 am tcapobianco@prospectiv.com wrote:
> > On 31 December 2010 05:14, Tony Capobianco <tcapobianco@prospectiv.com>
> >
> > wrote:
> >> esave_dw=> \d members
> >> Did not find any relation named "members".
> >> esave_dw=>
> >> esave_dw=> \d esave.members
> >>                     Table "esave.members"
> >>       Column        |            Type             | Modifiers
> >> ---------------------+-----------------------------+-----------
> >>  memberid            | numeric                     | not null
> >>  etc....
> >>
> >> How can I get this so I don't have to preface the \d with the schema
> >> name every time?
> >
> > Hi Tony, you should changes the default search_path for the specified
> > users.
> > http://sql-info.de/postgresql/schemas.html
> > take a look at practical schema usage section.
>
> Gibransyah,
> That did the trick!  Thanks for your help.  I modified my role name from
> developer to dev since I already have a dev schema.  Here's the steps I
> ran below to get it working:
>
> create role dev login;
> alter role dev set default_tablespace=dev;
> alter role dev set search_path=dev,staging, esave, support, email,public;
>
> grant usage on schema esave to dev;
> grant usage on schema dev to dev;
> grant select on members to dev;
> grant create on schema dev to dev;
> grant create on tablespace dev to dev;
>
> I am a little confused as to why I had to grant usage & create on dev to
> dev since it's both the dev role's default_tablespace and has a schema
> named after it.  Either way, this corrects my issue.  Thanks for your
> help!
>
> Tony

In my previous message I forgot to add the following.

The set commands and grants are not linked. Setting something does not
necessarily confer privileges for that object. The search_path for instance. It
really only sets up the search order for unqualified object names. What you can
see or do with those objects is determined by the privileges on those objects.
Those privileges come from either the role that created the object or are
GRANT(ed) by a sufficiently privileged role to another role.

--
Adrian Klaver
adrian.klaver@gmail.com


pgsql-sql by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: create role
Next
From: Bryce Nesbitt
Date:
Subject: " in transaction" can't be killed with pg_cancel_backend(). Is it a bug?