Re: SET ROLE and reserved roles - Mailing list pgsql-hackers

From Robert Haas
Subject Re: SET ROLE and reserved roles
Date
Msg-id CA+TgmoZGYy8bovAABRy3VkwiWPVeMV2SdbHDowhgWbNWnuqxBw@mail.gmail.com
Whole thread Raw
In response to Re: SET ROLE and reserved roles  (Stephen Frost <sfrost@snowman.net>)
Responses Re: SET ROLE and reserved roles  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Apr 13, 2016 at 6:53 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Requiring that SET ROLE be allowed will mean that many more paths must
> be checked and adjusted, such as in all of the CreateObject statements
> and potentionally many other paths that I'm not thinking of here, not
> the least of which are all of the *existing* checks near
> get_rolespec_oid/tuple which will require additional checks for the
> CURRENT_USER case to see if the current user is a default role.

I don't get it.  I think that these new roles should work just like
any other roles, except for existing at initdb time.  I don't see why
they would require checking or adjusting any code-paths at all.  It
would presumably have made the patch you committed smaller and
simpler.  The only thing you'd need to do is (approximately) not dump
them.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Pglogical questions and problems
Next
From: Robert Haas
Date:
Subject: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.