Re: alter user/role CURRENT_USER - Mailing list pgsql-hackers
| From | Adam Brightwell |
|---|---|
| Subject | Re: alter user/role CURRENT_USER |
| Date | |
| Msg-id | CAKRt6CRU3HFsxGoL+AgjsPwaN7y5M55OeTdURhCoSNLm+jcraA@mail.gmail.com Whole thread Raw |
| In response to | Re: alter user/role CURRENT_USER (Marti Raudsepp <marti@juffo.org>) |
| Responses |
Re: alter user/role CURRENT_USER
Re: alter user/role CURRENT_USER |
| List | 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
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
pgsql-hackers by date: