Re: alter user/role CURRENT_USER

Поиск
Список
Период
Сортировка
От Adam Brightwell
Тема Re: alter user/role CURRENT_USER
Дата
Msg-id CAKRt6CRU3HFsxGoL+AgjsPwaN7y5M55OeTdURhCoSNLm+jcraA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: alter user/role CURRENT_USER  (Marti Raudsepp <marti@juffo.org>)
Ответы Re: alter user/role CURRENT_USER
Re: alter user/role CURRENT_USER
Список pgsql-hackers
+RoleId:        CURRENT_USER                            { $$ = "current_user";}
+           | USER                                  { $$ = "current_user";}
+           | CURRENT_ROLE                          { $$ = "current_user";}
+           | SESSION_USER                          { $$ = "session_user";}

This is kind of ugly, and it means you can't distinguish between a
CURRENT_USER keyword and a quoted user name "current_user".

You are right.  I'm not sure I have an opinion on how clean it is, but FWIW, it is similar to the way that the 'auth_ident' type in the grammar is defined (though, not to imply that it makes it right).  As well, the originally proposed "RoleId_or_curruser" suffers from the same issue.  I'm going to go out on a limb here, but is it not possible to consider "current_user", etc. reserved in the same sense that we do with PUBLIC and NONE and disallow users/roles from being created as them?  I mean, after all, they *are* already reserved keywords.  Perhaps there is a very good reason why we wouldn't want to do that and I am sure there is since they have not been treated this way thus far.  If anyone would like to share why, then I'd very much appreciate the "lesson".

It's a legitimate user name, so the behavior of the following now changes:

CREATE ROLE "current_user";

Well, it does allow this one.
 
ALTER ROLE "current_user" SET work_mem='10MB';

However, you are right, it does interfere with this command (and pretty much ALTER ROLE in general).  :-/ Not sure what to offer there.
 
ALTER USER USER does not seem like sane syntax that should be
accepted.

I think that I agree, I can't imagine this being acceptable.

Taking a step back, I'm still not sure I understand the need for this feature or the use case.  It seems to have started as a potential fix to an inconsistency between ALTER USER and ALTER ROLE syntax (which I think I could see some value in).  However, I think it has been taken beyond just resolving the inconsistency and started to cross over into feature creep.  Is the intent simply to resolve inconsistencies between what is now an alias of another command?  Or is it to add new functionality?  I think the original proposal needs to be revisited and more time needs to be spent defining the scope and purpose of this patch.  

-Adam


--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Amit Langote"
Дата:
Сообщение: Re: On partitioning
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add CREATE support to event triggers