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

* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> > +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).

No, it's not right and it's an existing problem. :(

=*# create extension postgres_fdw;
CREATE EXTENSION
=# create server s1 foreign data wrapper postgres_fdw ;
CREATE SERVER
=*# create user mapping for "current_user" server s1;
CREATE USER MAPPING
=*# table pg_user_mappings;
-[ RECORD 1 ]-----
umid      | 24623
srvid     | 24622
srvname   | s1
umuser    | 16384
usename   | sfrost
umoptions |

> 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?

Maybe we could in some future release, but we can't for back-branches so
I'm afraid we're going to have to figure out how to fix this to work
regardless.

> 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".

You can still double-quote reserved words and use them in general.  What
we're talking about here are cases where a word can't be used even if
it's double-quoted, and we try really hard to keep those cases at an
absolute minimum.  We should also really be keeping a list of those
cases somewhere, now that I think about it..

> 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.

I agree that we should probably seperate the concerns here.  Personally,
I like the idea of being able to say "CURRENT_USER" in utility commands
to refer to the current user where a role would normally be expected, as
I could see it simplifying things for some applications, but that's a
new feature and independent of making role-vs-user cases more
consistent.
Thanks!
    Stephen