Re: alter user/role CURRENT_USER - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: alter user/role CURRENT_USER
Date
Msg-id 20141029.174739.199648648.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: alter user/role CURRENT_USER  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Hello, thank you all for many comments.

At the first, I removed changes for role-vs-user consistency and
remove all added role named other than current_user.

The followings are one-by-one answer for the comments so far,
please let me know if I missed anything.

- The necessity of the new function ResolveRoleId()
It is very brief function but used in many place where the rolename should be treated in the same way, so I think
encapsulationisneeded in some extent and in any form. It could be mergedwith get_role_oid.
 

- About changes in foreigncmds.c
I removed the refactoring using ResolveRoleId() in this patch.

- RoleId_or_curruser separate from RoleId.
There seems to be places where 'current_user' and like is notappropraite to occur such as CREATE USER. I don't mind to
removethenon-terminal if it is needless consideration.
 

- GRANT is not modified.
I thought GRANT is not appropriate but it seems appropriateseeing your example. And grantee takes "public". I
changedGRANT/REVOKEto take current_user in this patch.
 

- (not a comment) CREATE SCHEMA needed additonal aid
Schema name can be omitted in CREATE SCHEMA and role name isused for it, so "CREATE SCHEMA AUTHORIZATION
current_user"cratesthe schema "current_user" in the previous patch. Thisshould be the real name of current_user.
 

This patch is for reviewing at a glance for food of discussion
and tested very briefly (and what is worse, it might even not be
applicable). I'll repost more refined version in this way and
other portions.

At Tue, 28 Oct 2014 12:16:13 -0400, Stephen Frost <sfrost@snowman.net> wrote in
<20141028161613.GT28859@tamriel.snowman.net>
> * Kevin Grittner (kgrittn@ymail.com) wrote:
> > It is very important that a quoted identifier not be treated as a
> > keyword.  I would be very interested in seeing that list, and in
> > ensuring that it doesn't get any longer.
> 
> It's object specific and not handled through the grammar, so that gets
> pretty annoying. :/
> 
> The ones I could find by a quick look through backend/commands are:
> 
> roles
>   public
>   none
> 
> schemas
>   pg_*
> 
> operator
>   => (throws a warning at least)
> 
> There may be other cases that my quick review didn't find, of course.

Hmm... This seems to be another issue, though. I'll be careful
not to make it worse..

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: WAL format and API changes (9.5)
Next
From: Simon Riggs
Date:
Subject: Re: group locking: incomplete patch, just for discussion